Mobility Enhancement Rel-18

RAN1#110-bis-e

9.12 Further NR mobility enhancements

Please refer to RP-222332 for detailed scope of the WI on further NR mobility enhancements.

R1-2210695 Session notes for 9.12 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

R1-2210265 RAN1 Work Plan for Rel-18 Further NR Mobility Enhancements WI MediaTek Inc., Apple

9.12.1 L1 enhancements for inter-cell beam management

Including L1 measurement and reporting, beam indication, and dynamic switch mechanism among candidate serving cells (including SpCell and SCell).

R1-2208679 L1 enhancements to inter-cell beam management Ericsson

· Proposal 1 RAN1 develops beam indication and beam measurement for L1/L2 mobility that is independent of inter-cell beam management.

· Proposal 2 Further consider if L1/L2 mobility should be designed for a specific TCI framework.

· Proposal 3 The beam indication for L1/L2 mobility does not rely on RRC configuration of target TCI states.

· Proposal 4 The beam indication can contain a QCL source for subsequent DL receptions.

· Proposal 5 The beam indication contains a TA value for the target cell.

· Proposal 6 The beam indication contains ID if the active DL and UL BWPs for the target cells.

· Proposal 7 The L1/L2 mobility beam indication is carried by MAC CE.

· Proposal 8 The beam measurement reports to assist L1/L2 mobility include measurement information on serving and target cells.

· Proposal 9 The beam measurements for L1/L2 mobility should require only a minimum of configuration.

· Proposal 10 The configuration of beam measurements for L1/L2 mobility should not require that the NW specifies which PCIs should be measured.

· Proposal 11 The beam reporting for L1/L2 mobility is performed over MAC.

· Proposal 12 Study simplified event-driven reporting to assist L1/L2 mobility over MAC.

· Proposal 13 The intra-frequency measurements used for L1/L2 mobility have the same requirements as the intra-frequency measurements.

· Proposal 14 The inter-frequency measurements used for L1/L2 mobility have the same requirements as the inter-frequency measurements.

· Proposal 15 Send an LS to RAN4 describing the accuracy requirements for the measurements used for L1/L2 mobility.

· Proposal 16 The UE can be configured to store the QCL properties of a subset of the RSs it has reported for a limited period.

Decision: The document is noted.

R1-2209923 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

· Proposal 1: For candidate cells on the same frequency as serving cell, the dynamic beam indication from those candidate cells used in Rel-17 ICBM can be also supported in Rel-18 L1/L2 inter-cell mobility.

· Proposal 2: Study enhancement to support inter-frequency L1 beam measurement/reporting.

· Proposal 3: Study event triggered L1 beam measurement/reporting.

· Proposal 4: Study filtered L1 cell/beam/beam-group measurement/reporting and its interaction with legacy L3 measurement/reporting.

· Proposal 5: New L1/L2 signaling is needed to indicate cell switch for Rel-18 L1/L2 inter-cell mobility. DCI based indication is preferred.

o Support both single cell switch and cell group switch.

o At least the cell/cell group ID of target cell/cell group should be indicated.

· Proposal 6: For beam indication of target cell, beam indication method in Rel-17 ICBM is starting point.

Decision: The document is noted.

R1-2208406 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2208500 Discussion on L1 enhancements for L1/L2-based inter-cell mobility Nokia, Nokia Shanghai Bell

R1-2208509 L1 enhancements for inter-cell beam management ZTE

R1-2208570 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2208664 Discussion on L1 enhancements for L1/L2 mobility vivo

R1-2208747 L1 enhancements for inter-cell beam management Lenovo

R1-2208805 Discussions on Inter-cell beam management enhancement OPPO

R1-2208884 On Intercell beam management enhancement for NR mobility enhancement Google

R1-2208905 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2208958 On L1 enhancements for inter-cell beam management CATT

R1-2209024 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2209073 L1 Enhancements for Inter-cell Beam Management Intel Corporation

R1-2209203 L1 enhancements for inter-cell beam management InterDigital, Inc.

R1-2209268 Discussion on L1 enhancements and Dynamic switch mechanism xiaomi

R1-2209359 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2209428 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2209498 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2209603 On L1 enhancements for inter-cell mobility Apple

R1-2209754 On L1 enhancements for inter-cell beam management Samsung

R1-2210008 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

[110bis-e-R18-Mobility-01] – Yosuke (Fujitsu)

Email discussion on L1 enhancements for inter-cell beam management by October 19

- Check points: October 14, October 19

R1-2210414 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Oct 12th GTW session

Agreement

· For Rel-18 L1/L2 mobility, L1 intra-frequency measurement for candidate cell is supported

o At least the following aspects are for RAN1 further study:

§ RAN1 assumes Rel-17 ICBM CSI measurement as starting point.

§ Whether and how to apply relaxation for the restrictions imposed on the Rel-17 intra-frequency L1 non-serving cell measurement defined in 9.13.2 of TS38.133, where RAN4 impact is foreseen, e.g.

· SFN offset alignment compared with serving cell

· BWP setting, i.e. non-serving cell SSB should be covered by serving cell active BWP

· Introduction of symbol level gap or SMTC for larger Rx timing difference (i.e. larger than CP length)

§ Commonality with intra-frequency L3 measurement

§ Commonality with L1 inter-frequency measurement for measurement configuration

· Send an LS to RAN4 (CC RAN2)

o RAN1 to ask RAN4 if the restriction on e.g., SFN offset alignment, BWP setting and Rx timing difference, etc, described in 9.13.2 of TS38.133 for intra-frequency L1 non-serving measurement can be relaxed or not.

o RAN1 assumes Rel-17 ICBM CSI measurement as starting point.

Agreement

· For Rel-18 L1/L2 mobility,

o SSB is supported for L1 intra-frequency measurement

o SSB is supported for L1 inter-frequency measurement if inter-frequency L1 measurements are supported

· Further study the following L1 measurement RS for candidate cell

o CSI-RS for tracking, beam management, CSI and mobility, CSI-IM, which is for L1 intra-frequency and L1 inter-frequency (if supported)

Agreement

· For candidate cell measurement for Rel-18 L1/L2 mobility,

o L1-RSRP is supported for intra-frequency candidate cell measurement.

o Further study the following measurement quantities for candidate cell measurement

§ L1-RSRP for inter-frequency (if supported)

§ L1-SINR for intra-frequency and inter-frequency (if supported)

· FFS: to assess the use case and the benefit of UL measurement instead of/in addition to DL L1 measurement, which includes:

o How the UL measurement result is used, e.g. handover decision

o Signals/channels used for UL measurement, e.g. SRS

o Spec impact including other WGs, e.g. definition of gNB measurement, interface to transfer RS configuration or measurement results

o Note: The next discussion will take place based on companies’ contribution in future meeting.

R1-2210612 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Oct 17th GTW session

Agreement

For Rel-18 L1/L2 mobility, further study the potential RAN1 spec impact of L1 inter-frequency measurement

The definition and scenarios of L1 inter-frequency measurement is determined by RAN4, and RAN1 assumes at least the following until receiving their confirmation

The scenarios not included in intra-frequency are regarded as inter-frequency, which includes at least the following scenarios:

The frequency of the measured RS not covered by any of the active BWPs of SpCell and Scells configured for a UE, but covered by some of the configured BWPs of SpCell and Scells configured for a UE.
The frequency of the measured RS not covered by any of the configured BWPs of SpCell and Scells configured for a UE

At least the following aspect is studied:

Commonality with L1 intra-frequency measurement for measurement configuration

Send an LS to RAN4 (CC RAN2)

RAN1 would like to confirm our understanding that the supported scenarios not included in intra-frequency are regarded as inter-frequency, which includes at least the following scenarios:

The frequency of the measured RS not covered by any of the active BWPs of SpCell and Scells configured for a UE, but covered by some of the configured BWPs of SpCell and Scells configured for a UE.
The frequency of the measured RS not covered by any of the configured BWPs of SpCell and Scells configured for a UE

It is RAN1 understanding that the introduction of measurement gap and SMTC for L1 inter-frequency measurement, if any, is expected to be a RAN4 issue
Note: this content is included in the LS agreed for intra-frequency L1 measurement

Agreement

For L1 measurement report for Rel-18 L1/L2 mobility, further study the following mechanisms:

Report as UCI on PUCCH or PUSCH

Periodic report on PUCCH, semi-persistent report on PUCCH/PUSCH, and aperiodic report on PUSCH
Potential enhancements to Rel-17 ICBM report format to accommodate Rel-18 scenarios, e.g.

Inter-frequency measurement, if supported
Increasing the maximum number of reported beams, which is 4 for Rel-17 ICBM
Flexible size beam report, e.g., two-part UCI (e.g., the 1st part contains the best beam/cell and the number (e.g., N) of reported beams/cells, the 2nd part contains the rest (N-1) beams/cells
Reducing the reporting overhead by e.g. choosing beams/cells per frequency or across frequencies to report (FFS how)

Report on MAC CE

Both gNB scheduled and/or UE initiated (if supported) report are studied

Agreement

RAN1 to further study if the beam indication of candidate cell(s) L1/L2 mobility should be designed for a specific TCI framework below, and their potential RAN1 spec impact.

· Option A: Beam indication for Rel-18 L1/L2 mobility is designed based on Rel-17 TCI framework mechanism

· Option B: Beam indication for Rel-18 L1/L2 mobility is designed based on Rel-15 TCI framework mechanism

· Option C: Beam indication for Rel-18 L1/L2 mobility is designed based on both Rel-15 and Rel-17 TCI framework mechanisms

R1-2210675 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

Agreement

Send an LS to RAN2/RAN3 asking the clarification on intra-/inter-DU scenario:

· RAN1 has started the discussion on the configuration for L1 measurement and TCI states for candidate cells. Regarding the following RAN2 agreements captured in RAN2 LS (R1-2208331/R2-2209257), it is not clear for RAN1 which kind of information/configuration for candidate cell(s) are available at a serving cell for inter-DU case for Rel-18 L1/L2 mobility. Thus, companies have different understanding on the implication of the sentence “as much commonality as reasonable” in the LS.

o The design for intra-DU and inter-DU L1/L2-based mobility should share as much commonality as reasonable. FFS which aspects need to be different.

· RAN1 respectfully asks RAN2 and RAN3 if the serving DU knows the measurement RS configuration and TCI state configuration of cells served by another DU.

Agreement

Send an LS to RAN2, 3 and 4 to inform them of the agreements under A.I 9.12.1 and A.I. 9.12.2.

If the LS related proposal under A.I 9.12.1 and 9.12.2 are agreed, the contents are also included.

(See post meeting email discussion)

Decision: As per email decision posted on Oct 20th,

Agreement

From RAN1 perspective, the following scenarios can be considered for Rel-18 L1/L2 mobility for beam indication timing. This will be updated depending on further RAN1 assessment and RAN2 decision on the time chart

· Scenario 1: Beam indication before cell switch command

· Scenario 2: Beam indication together with cell switch command

· Scenario 3: Beam indication after cell switch command

Interested companies are encouraged to further study the validity of the scenarios and the potential spec impact.

Agreement

Interested companies are encouraged to perform technical analysis of the cell switch command from a RAN1 point of view, e.g.

· Necessary information included in the command, which is relevant for RAN1 discussion

· Necessary number of bits for the information

· L1 impact or concern to use DCI or MAC CE for L1/L2 cell switch command

Agreement

RAN1 to further study the potential RAN1 enhancements and spec impact to perform at least the following procedures prior to the reception of L1/L2 cell switch command aiming at the reduction of handover delay / interruption

· DL synchronization for candidate cell(s)

· TRS tracking for candidate cell(s)

· CSI acquisition for candidate cell(s)

· Activation/Selection of TCI states for candidate cell(s), if feasible

· Note: Uplink synchronization aspect will not be discussed under this A.I.

· FFS: Whether the above procedures prior to the reception of L1/L2 cell switch command can be performed on candidate cell when it is deactivated SCell (if defined in RAN2)

Detailed discussion will be commenced after receiving RAN2 LS.

9.12.22 Timing advance management to reduce latency

R1-2208383 Latency Reduction and Target TA Determination for L1/L2 Mobility FUTUREWEI

· Proposal 1: Before cell switch command is received, if the RSRP of a candidate cell is above a threshold, the UE starts acquiring, tracking and storing the candidate’s DL timing information including RSTD and MIB.

· Proposal 2: Upon receiving the cell switching command, the UE applies the stored most recent RSTD and MIB to achieve the DL synchronization of the target cell.

· Proposal 3: Support RACH-less access to the target during the mobility.

· Proposal 4: Upon reception of target access command, UE indication of the SSB/CSI-RS selected as the target beam is supported for mobility RACH-less access. Indication methods and details are FFS.

· Observation 6: For intra-DU TRP switching, the TA of the target TRP for after switching can be obtained by UE adjusting the TA obtained before switch without using RACH.

· Proposal 5: For intra-DU TRP switch, before the UL transmission to the target TRP started, the UE determines TA of the target TRP by adjusting the TA-update from the network with RSTD.

· Proposal 6: For inter-DU L1/L2 mobility, support the network assisted target_TA determination performed at the UE by adjusting the Source_TA with RSTD and a network TA adjustment factor.

Decision: The document is noted.

R1-2208407 Timing advance management to reduce latency Huawei, HiSilicon

R1-2208501 Discussion on timing advance management for L1/L2-based inter-cell mobility Nokia, Nokia Shanghai Bell

R1-2208510 Enhancements on TA management to reduce latency ZTE

R1-2208571 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2208665 Discussion on TA management for L1/L2 moblity vivo

R1-2208748 Timing advancement management for L1L2 mobility Lenovo

R1-2208806 Discussions on Timing Advance Management OPPO

R1-2208885 On TA management for NR mobility enhancement Google

R1-2208959 On timing advance management to reduce latency CATT

R1-2209074 On Timing Advance Management Intel Corporation

R1-2209204 Timing advance management to reduce latency InterDigital, Inc.

R1-2209269 Discussion on Timing advance management xiaomi

R1-2209360 Discussion on timing advance management to reduce latency CMCC

R1-2209499 UL Timing management to reduce handover latency MediaTek Inc.

R1-2209542 Timing advance management to reduce latency Ericsson

R1-2209604 Timing advance management to reduce mobility latency Apple

R1-2209755 Non-serving cell TA management for NR mobility enhancement Samsung

R1-2209924 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2210009 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2210200 Timing advance alignment with low latency Rakuten Symphony

[110bis-e-R18-Mobility-02] – Xin (CATT)

Email discussion on TA management by October 19

- Check points: October 14, October 19

R1-2210390 Moderator summary on timing advance management: Round 1 Moderator (CATT)

From Oct 17th GTW session

Agreement

Support TA acquisition of candidate cell(s) before cell switch command is received in L1/L2 based mobility.

· FFS: whether this can be applied to candidate cell when it is deactivated SCell (if defined in RAN2).

From Oct 19th GTW session

Agreement

On mechanism to acquire TA of the candidate cells, the following solutions can be further studied:

· RACH-based solutions

o e.g., PDCCH ordered RACH, UE-triggered RACH, higher layer triggered RACH from NW other than L3 HO cmd

· RACH-less solutions

o e.g., SRS based TA acquisition, Rx timing difference based, RACH-less mechanism as in LTE, UE based TA measurement (including UE based TA measurement with one TAC from serving cell)

Agreement

For TA acquisition of a candidate cell before cell switch command is received, study at least the following alternatives of associating TA/TAG to candidate cell:

· Alt1: Associate TA/TAG and candidate cell implicitly, e.g.,

o the association between TA/TAG and TCI states can be configured

· Alt2: Associate TA/TAG and candidate cell explicitly, e.g.,

o the association is provided as a part of candidate cell(s) configuration

o the association between TA/TAG and SSB(s)/TRS(s) is provided as a part of candidate cell(s) configuration

RAN1#111

9.12 Further NR mobility enhancements

Please refer to RP-222332 for detailed scope of the WI on further NR mobility enhancements.

R1-2212850 Session notes for 9.12 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

Endorsed and contents incorporated below.

[111-R18-Mobility] – Parisa (MediaTek)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.12.1 L1 enhancements for inter-cell beam management

Including L1 measurement and reporting, beam indication, dynamic switch mechanism among candidate serving cells (including SpCell and SCell), and discussions on RAN2 triggered issues in R1-2210810. For the RAN2 triggered issues, please capture the discussions in a separate section for better work management during the meeting.

R1-2210897 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2210942 L1 enhancements for inter-cell beam management ZTE

R1-2211028 Discussion on L1 enhancements for L1/L2 mobility vivo

R1-2211053 L1 enhancements to inter-cell beam management Ericsson

R1-2211083 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2211130 On Intercell beam management enhancement for NR mobility enhancement Google

R1-2211180 Discussion on L1 enhancements for inter-cell beam management CATT

R1-2211250 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2211297 L1 enhancements for inter-cell beam management Lenovo

R1-2211306 Discussion on L1 enhancements for L1/L2-triggered mobility Nokia, Nokia Shanghai Bell

R1-2211322 L1 enhancements for inter-cell beam management InterDigital, Inc.

R1-2211346 Discussion on L1 enhancements for inter-cell beam management xiaomi

R1-2211418 L1 Enhancements for Inter-cell Beam Management Intel Corporation

R1-2211440 Discussions on Inter-cell beam management enhancement OPPO

R1-2211702 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2211753 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2211832 L1 enhancements to inter-cell beam management Apple

R1-2211873 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2212004 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2212068 On L1 enhancements for inter-cell beam management Samsung

R1-2212140 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2212235 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2212741 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Nov 15th session

Agreement

· For Rel-18 LTM, L1 inter-frequency measurement is supported from RAN1 point of view.

Agreement

· Regarding the potential RAN1 enhancements to reduce the handover delay / interruption for Rel-18 LTM

o Support at least DL synchronization for candidate cell(s) based on at least SSB before cell switch command

§ Further study the necessary mechanism, e.g. signaling and UE capability

Agreement

For L1 measurement report for Rel-18 L1/L2 mobility, if UE event triggered report for L1 measurement is supported based on further study

· At least the following aspects may be considered

o How to define UE event and exact definition of events,

o Report container

o Resource allocation/assignment for UE event triggered report

o Necessity of indication to gNB when the condition UE event is met, and how

o Necessity to define the condition to start/stop the reporting,

o Contents of the report/reporting format, PCI, RS ID, measurement result etc.

o The interaction with filtered L1 measurement results (if supported)

o Support of simultaneous configuration of both UE event triggered and any of periodic/semi-persistence/aperiodic reporting, and solutions when both of them are configured.

o Report destination, whether the report is sent to serving cell only or can be sent to one or more candidate cell(s).

o Benefit when L3 measurement is involved

R1-2212858 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Nov 17th session

Agreement

Send an LS to RAN2, 3 and 4 to inform them of the agreements under A.I 9.12.1 and A.I. 9.12.2 at RAN1#111.

Agreement

For candidate cell measurement for Rel-18 LTM,

· SSB based L1-RSRP is supported for intra-frequency measurement

· SSB based L1-RSRP is supported for inter-frequency measurement from RAN1 point of view

· FFS: L1-SINR, CSI-RS based L1-RSRP

Agreement

The beam indication of candidate cell(s) for Rel-18 LTM should be designed based on the following:

· Beam indication for Rel-18 LTM is designed based on Rel-17 unified TCI framework, if both serving cell and candidate cell support Rel-17 unified TCI framework

· FFS: whether/how to design mechanism for Beam indication for Rel-18 LTM when at least one from serving cell and candidate cell supports only Rel-15 TCI framework.

· Note: How and whether to indicate the new serving cell(s) and timing for beam indication are separately discussed

Agreement

For gNB scheduled L1 measurement report for Rel-18 LTM, report as UCI is supported

Semi-persistent report on PUSCH, and aperiodic report on PUSCH are supported

FFS: periodic and semi-persistent PUCCH

In a single report instance, report for serving cell and candidate cell(s) for intra-frequency and/or inter-frequency can be included.

Agreement

For beam indication timing for Rel-18 LTM,

Support Scenario 2: Beam indication together with cell switch command,

For Rel-17 unified TCI framework,

Beam indication indicates TCI state for each target serving cell

FFS: Scenario 1: Beam indication before cell switch command
FFS: Scenario 3: Beam indication after cell switch command

FFS: Activation of TCI state(s) of target serving and/or candidate cell(s).

R1-2212947 DRAFT LS on RAN1 agreements for L1/L2-based inter-cell mobility Fujitsu, CATT

Decision: As per decision on Nov 18th, the draft LS is endorsed. Final LS is approved in R1-2212948.

Final FL summary in R1-2212946.

9.12.22 Timing advance management to reduce latency

R1-2210853 Comparison of TA acquisition schemes for L1/L2 Mobility FUTUREWEI

R1-2210898 Timing advance management to reduce latency Huawei, HiSilicon

R1-2210943 Enhancements on TA management to reduce latency ZTE

R1-2211029 Discussion on TA management for L1/L2 Mobility vivo

R1-2211131 On TA management for NR mobility enhancement Google

R1-2211181 Discussion on timing advance management to reduce latency CATT

R1-2211251 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2211298 Timing advancement management for L1L2 mobility Lenovo

R1-2211307 Discussion on timing advance management for L1/L2-triggered mobility Nokia, Nokia Shanghai Bell

R1-2211323 Timing advance management to reduce latency InterDigital, Inc.

R1-2211347 Discussion on Timing advance management xiaomi

R1-2211419 On Timing Advance Management Intel Corporation

R1-2211441 Discussions on Timing Advance Management OPPO

R1-2211553 Timing advance management for L1/L2 Mobility Ericsson

R1-2211703 Discussion on timing advance management to reduce latency CMCC

R1-2211833 Timing advance management to reduce latency Apple

R1-2212005 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2212069 Candidate cell TA acquisition for NR L1/L2 mobility enhancement Samsung

R1-2212141 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2212239 UL Timing management to reduce handover latency MediaTek Inc.

R1-2212321 Reduced latency for inter-cell beam management Rakuten Symphony

R1-2212689 Moderator summary on Timing advance management: Round 1 Moderator (CATT)

From Nov 15th session

Agreement

On mechanism to acquire TA of the candidate cell(s) in Rel-18 LTM, at least support PDCCH ordered RACH.

· The PDCCH order is only triggered by source cell

· FFS: the details including content of DCI, RACH resource configuration, RAR transmission mechanism, etc.

· Note: any other RACH-based solutions are for discussion separately

Agreement (made in RAN1#110b-e)

Support TA acquisition of candidate cell(s) before cell switch command is received in L1/L2 based mobility.

· FFS: whether this can be applied to candidate cell when it is deactivated SCell (if defined in RAN2)

R1-2212815 Moderator summary on Timing advance management: Round 2 Moderator (CATT)

From Nov 16th session

Agreement

For PDCCH ordered RACH in LTM, at least the following enhancements are supported

· Introduce indication of candidate cell and/or RO of candidate cell in DCI

· configuration of RACH resource for candidate cell(s) is provided prior to the PDCCH order

· FFS: whether/how to transmit RAR

R1-2212863 Moderator summary on Timing advance management: Round 3 Moderator (CATT)

From Nov 17th session

Agreement

On whether RAR is needed for PDCCH ordered RACH for a candidate cell in LTM, the following alternatives are considered for further study

Alt 1: RAR is needed
Alt 2: RAR is not needed

Note: If Alt 2 is supported, TA value of candidate cell is indicated in cell switch command

Alt 3: whether RAR is needed can be configured

Agreement

TA updating (i.e. re-acquisition of TA) for candidate cell can be triggered by NW.

same triggering mechanism reuse the initial TA acquisition, i.e., PDCCH order triggered RACH in a candidate cell

RAN1#112

9.12 Further NR mobility enhancements

Please refer to RP-223520 for detailed scope of the WI on further NR mobility enhancements.

R1-2302068 Session notes for 9.12 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

[112-R18-Mobility] – Yosuke (Fujitsu)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.12.1 L1 enhancements for inter-cell beam management

Including L1 measurement and reporting, beam indication, dynamic switch mechanism among candidate serving cells (including SpCell and SCell), and discussions on RAN2 triggered issues in R1-2210810. For the RAN2 triggered issues, please capture the discussions in a separate section for better work management during the meeting.

R1-2300056 L1 enhancements for inter-cell beam management FUTUREWEI

R1-2300128 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2300145 FL plan on L1 enhancements for LTM at RAN1#112 Moderator (Fujitsu)

R1-2300188 L1 enhancements for inter-cell beam management ZTE

R1-2300239 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2300311 Discussions on Inter-cell beam management enhancement OPPO

R1-2300335 L1 enhancements to inter-cell beam management Ericsson

R1-2300384 Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2300474 Discussion on L1 enhancements for L1L2 mobility vivo

R1-2300488 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2300517 L1 enhancements for inter-cell beam management Lenovo

R1-2300536 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2300557 Discussion on L1 enhancements for inter-cell beam management in LTM Xiaomi

R1-2300662 Further discussions on L1 enhancements for inter-cell beam management CATT

R1-2300757 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2300769 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2300891 Discussion on L1 enhancements for inter-cell beam management Sony

R1-2300967 L1 Enhancements for Inter-cell Beam Management Intel Corporation

R1-2301024 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2301161 Discussion on inter-cell beam management Rakuten Mobile, Inc

R1-2301167 Discussion on L1 enhancements for inter-cell beam management Google

R1-2301169 L1 enhancements for inter-cell beam management InterDigital Communications

R1-2301208 Discussion on L1 measurement configuration for LTM Panasonic

R1-2301287 On L1 enhancements for inter-cell beam management Samsung

R1-2301369 L1 Enhancements to Inter-Cell Beam Management Apple

R1-2301436 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2301514 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2301576 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2300146 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Tuesday session

Agreement

· RAN1 shares the same understanding as RAN2 on agreement:

o The LTM mobility trigger information is conveyed in a MAC CE

· The same MAC CE is used for the LTM triggering.

Agreement

The agreement on scenario 2 (Beam indication together with cell switch command) at RAN1#111 is further clarified as the following:

· Beam indication for the target cell(s) is conveyed in the MAC CE used for LTM triggering for scenario 2

R1-2302001 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Wednesday session

Agreement

For L1-RSRP measurement RS configuration

· For SSB based L1-RSRP measurement:

o As a starting point, at least the following information needs to be provided to a UE, e.g.

§ For intra- and inter- frequency: PCI or logical ID (e.g., as being defined in R17 ICBM), time domain (e.g. SMTC or periodicity and SSB position in burst)

§ For inter-frequency: frequency domain location (e.g. center frequency), SCS

§ FFS: transmission power (for pathloss calculation)

o Note: other parameters included in the configuration can be further discussed

o Including above agreement into the LS

· The detailed design of RRC structure is up to RAN2, and send an LS to RAN2 to request to work on the RRC structure design on the measurement configuration.

o Following RAN1 understanding will be provided in the LS

§ RAN1 has discussed the following configuration options for L1 measurement configurations for SSB till RAN1#112:

· Option 1) Configurations for L1 measurement RS is provided under ServingCellConfig for the serving cells

o is useful to reuses the mechanism for Rel-17 ICBM and necessary information to support inter-frequency measurement will be added there.

· Option 2) Configurations for L1 measurement RS is provided separately from ServingCellConfig for the serving cells and CellGroupConfig for the candidate cells

o is useful to avoid the duplicated configurations for L1 measurement RSs, [and avoid UE to process configurations ~~for L1 measurement RS~~ provided under CellGroupConfig for the candidate cells]

· Option 3) Configurations for L1 measurement RS is provided under CellGroupConfig for the candidate cells

o can achieve the similar benefit as Option 2) by directly referring to the candidate cell configurations.

§ Note RAN2 has a full flexibility to design the whole RRC structure design.

§ RAN1 believes this is RAN2 expert region, and respectfully asks RAN2 to finalize the RRC structure design after RAN1 finalizes the discussion on RRC parameters.

§ It is noted that RAN1 foresees the necessity of similar discussions on TCI state pool for candidate cells and L1 measurement report configurations.

R1-2302002 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Thursday session

Agreement

Send an LS to RAN2,3,4 on the RAN1 agreements in this meeting

· All agreements in AI 9.12.1 and 9.12.2 in RAN1#112 are included

· The LS contents agreed in AI 9.12.1 (on L1 measurement configuration) and AI 9.12.2 (on RAR) are also included

R1-2302195 FL summary 4 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Friday session

Agreement

· At least for Rel-17 unified TCI framework based beam indication included in cell switch command (i.e. scenario 2), beam indication applies to signals/channels that follow or are configured to follow Rel-17 unified TCI at the target cell(s)

· FFS: beam indication for mTRP case

R1-2302193 DRAFT LS on L1 measurement RS configuration and PDCCH ordered RACH for LTM Moderator (Fujitsu), CATT

Decision: R1-2302193 is endorsed in principle by appending latest agreements. Final LS is approved in R1-2302194.

Final FL summary in R1-2302196.

9.12.22 Timing advance management to reduce latency

R1-2300057 Discussion of the merits of UE based RACH-less TA acquisition for LTM FUTUREWEI

R1-2300129 Timing advance management to reduce latency Huawei, HiSilicon

R1-2300189 Enhancements on TA management to reduce latency ZTE

R1-2300240 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2300312 Discussions on Timing Advance Management OPPO

R1-2300385 Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2300475 Discussion on TA management for L1L2 mobility vivo

R1-2300490 Discussion on TA management for LTM FGI

R1-2300518 Timing advancement management for L1L2 mobility Lenovo

R1-2300537 Enhancements on TA management for mobility LG Electronics

R1-2300558 Discussion on Timing advance management Xiaomi

R1-2300663 Discussion on time advance management to reduce latency CATT

R1-2300968 On Timing Advance Management Intel Corporation

R1-2301025 Discussion on timing advance management to reduce latency CMCC

R1-2301035 Discussion on TA management to reduce latency KDDI Corporation

R1-2301095 Timing advance management for L1/L2 Mobility Ericsson

R1-2301168 Discussion on timing advance management to reduce latency Google

R1-2301170 Timing advance management to reduce latency InterDigital Communications

R1-2301288 Candidate cell TA acquisition for NR L1/L2 mobility enhancement Samsung

R1-2301370 Timing advance management for L1/L2 Mobility Apple

R1-2301437 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2301515 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2301583 UL Timing management to reduce handover latency MediaTek Inc.

R1-2301893 Moderator summary on Timing advance management for LTM: Round 1 Moderator (CATT)

From Tuesday session

Agreement

For Rel-18 LTM, Random Access Preamble indices and indication of RACH occasions with the associated SSB indices are configured for each candidate cell.

Note: the detailed signalling is left to RAN2.

Agreement

The PDCCH order from the source cell contains the indication of candidate cell.

· The reserved bit(s) in DCI format 1_0 for PDCCH order can be used for indication of cell identity

R1-2302016 Moderator summary on Timing advance management for LTM: Round 2 Moderator (CATT)

From Wednesday session

Agreement

For PDCCH ordered-RACH for candidate cell(s), RAR reception can be configured/indicated

· If reception of RAR is not configured/indicated (without RAR)

o TA value of candidate cell is indicated in cell switch command

o FFS: whether UE should re-transmit PRACH when reception of RAR is not configured/indicated

o FFS: how UE determine the transmit power of subsequent PRACH triggered by PDCCH order

· If reception of RAR is configured/indicated (with RAR), FFS

o whether RAR is received from serving cell or candidate cell

§ if RAR is received from candidate cell, whether Type1-PDCCH CSS of the candidate cell is configured to the UE

o content of RAR

· FFS: signaling for configuration/indication of whether RAR needs to be received

· UE can report the support combination of with RAR only and without RAR only, where support of one default scheme is the baseline UE approach for LTM

· Send LS to RAN2 and RAN3 to check the feasibility about this agreement

· Note: Definition of candidate cells is up to RAN2

R1-2302075 Moderator summary on Timing advance management for LTM: Round 3 Moderator (CATT)

From Thursday session

Agreement

· For PDCCH-order based RACH for TA measurement for candidate cells, legacy CBRA is not supported

Agreement

On whether UE should initiate re-transmit PRACH when reception of RAR is not configured/indicated, down select one from the following alternatives.

· Alt 1: UE autonomous re-transmission of PRACH is not allowed (e.g., by setting the number of allowed PRACH transmission to the minimum value of PreambleTransMax=1)

· Alt 2: UE autonomous Re-transmission of PRACH is allowed,

o The number of PRACH transmission will be defined e.g. set the times of RACH transmission to the minimum value of PreambleTransMax

Agreement

If reception of RAR is configured/indicated, RAR contains at least TA of candidate cell.

· The maximum number of TA values memorized by UE is a UE capability

· FFS: whether other parameters such as UE ID, candidate cell ID etc. is contained in RAR

Agreement

Whether RAR needs to be received is configured by RRC.

R1-2302165 Moderator summary on Timing advance management for LTM: Round 4 Moderator (CATT)

From Friday session

Agreement

Study at least the following issues on PDCCH-order based PRACH for candidate cell that is not UL serving cell, i.e. without PUCCH/PUSCH configured

· Whether gap between the DCI and PRACH longer than timeline defined in spec is needed

· Any impact/interruption on UL Tx of serving CCs due to the PRACH Tx

Working Assumption

UE-based TA measurement (UE derives TA based on Rx timing difference between current serving cell and candidate cell as well as TA value for the current serving cell) is supported.

· Corresponding UE capability is to be introduced to support UE-based TA measurement

· For a UE reports support of this capability, configuration of UE-based TA measurement is supported

· FFS: other impacts on RAN1 spec

RAN1#112-bis-e

9.10 Further NR mobility enhancements

Please refer to RP-223520 for detailed scope of the WI on further NR mobility enhancements.

R1-2304173 Session notes for 9.10 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

9.10.1 L1 enhancements for inter-cell beam management

R1-2302315 L1 enhancements for inter-cell beam management FUTUREWEI

R1-2302368 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2302410 FL plan on L1 enhancements for LTM at RAN1#112bis-e Moderator (Fujitsu, MediaTek)

R1-2302413 L1 enhancements to inter-cell beam management Ericsson

R1-2302423 L1 enhancements for inter-cell beam management ZTE

R1-2302504 Discussion on L1 enhancements for L1/L2 mobility vivo

R1-2302568 Discussions on Inter-cell beam management enhancement OPPO

R1-2302619 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2302730 L1 enhancements for inter-cell beam management Lenovo

R1-2302752 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2302819 L1 Enhancements for Inter-cell Beam Management Intel Corporation

R1-2302830 Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2302860 Discussion on L1 enhancements for inter-cell beam management Sony

R1-2302867 Discussion on L1 enhancements for L1L2-triggered mobility Panasonic

R1-2302870 Discussion on L1 enhancements for inter-cell beam management CATT

R1-2302914 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2302966 Discussion on L1 enhancements for inter-cell beam management Xiaomi

R1-2303082 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2303148 On L1 enhancements for inter-cell beam management Samsung

R1-2303253 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2303288 Discussion on L1 enhancements for inter-cell mobility KDDI Corporation

R1-2303331 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2303410 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2303455 Discussion on L1 enhancements for inter-cell beam management InterDigital, Inc.

R1-2303503 L1 enhancements to inter-cell beam management Apple

R1-2303518 Discussion on L1 enhancements for inter-cell beam management Google

R1-2303610 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2303727 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

[112bis-e-R18-Mobility-01] – Yosuke (Fujitsu)

Email discussion on L1 enhancements for inter-cell beam management by April 26 - extended till April 28th

- Check points: April 21, April 26

R1-2303021 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

Presented in April 17th GTW session.

R1-2303022 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From April 19th GTW session

Agreement

· Adopt Alt.2 for beam indication of target cell(s) and TCI state activation for candidate cell(s) (if supported) ,

o Alt. 1: By indicating RS identifier, i.e. mapping between RS identifier and Rel-17 unified TCI state is done by a UE

o Alt. 2: By indicating Rel-17 TCI state index

R1-2304090 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From April 21st GTW session

Agreement

From RAN1 point of view, at least the following information can be included in the cell switch command, which is conveyed by MAC CE

Information to identify the target cell(s)

The details including bit number are designed by RAN2

TA related information (details up to the discussion in A.I. 9.10.2)
1 joint or 1 pair of UL and DL unified TCI State index for the target Cell

Note: discussion on target SpCell is not precluded

Active DL and UL BWPs for the target cell
FFS: Triggering of aperiodic TRS transmitted from the target cell
FFS: Triggering the CSI acquisition of the target cell and reporting to the target cell
FFS: Triggering of aperiodic SRS transmission to the target cell

· FFS: C-RNTI

FFS: the presence of each field (i.e. always present or configurable)

R1-2304091 FL summary 4 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From April 25th GTW session

Agreement

For the beam selection for SSB based L1-RSRP measurement report,

· Beam selection is performed across the L cells from configured (or activated, if introduced) cells, i.e. M beams for each of the L cells

o FFS: How to select the L cells and M beams per cells is up to UE

· M x L beams are reported in a single report instance

o Max values of M and L are based on UE capability, and at least M x L=4 is supported as a UE capability, other UE capabilities are FFS

§ FFS if UE is allowed to report less than M x L beams

o The values of M and L are configured to the UE in the reporting configuration

· FFS: The following configurability is introduced in the report configuration

o 1) Whether serving cell is always selected in the L cell selection performed by the UE, and applicable when a UE is configured with L>=2

o 2) at least one of the inter-frequency cells is always selected in the L cell selection performed by the UE, and applicable when a UE is configured with L>=2 and at least one cell in inter-frequency

Agreement

For the Rel-17 unified TCI based beam indication in Rel-18 LTM, at least Alt 1 is supported:

Alt 1: TCI state activation of a candidate cell is received before the reception of beam indication of the candidate cell,
Alt 2: TCI state activation of a candidate cell is received together with the reception of beam indication of the candidate cell

FFS: signalling details for TCI state indication, if both activation and indication are done in the same MAC CE message carrying switch command

Alt 3: Alt 1 and/or Alt 2 can be supported based on the UE capability

FFS: signalling details for TCI state activation

FFS: For Alt 1, whether/how TCI state activation for candidate cell(s) is allowed

Note: If scenarios 1 and 3 are to be supported other beam indication/TCI activation timing relationships are not precluded.

Decision: As per email decision posted on April 27th,

Agreement

· Periodic and semi-persistent report on PUCCH are also supported for gNB scheduled L1-measurement reporting.

Agreement

· RRC parameter ss-PBCH-BlockPower for candidate cells is included in the LTM configuration.

o UE needs the parameter to (at least) perform RACH towards candidate cells

o Note: how to capture this parameter and RRC structure are up to RAN2

Agreement

Companies are encouraged to study the beam application time for Rel-18 LTM, which may be different from that without serving cell change

· Definition of the beam application time

· The exact value(s), condition and UE capability

· Consider the interaction with the application of the candidate RRC configuration.

Conclusion

Whether active DL and UL BWP of the target Cell/SpCell field, within the cell switch command, is always present or not is left to RAN2 decision.

Working Assumption

On the presence of beam indication within cell switch command, at least for scenario 2, following is supported:

· A field to indicate 1 joint or 1 pair of UL and DL unified TCI State index for the target cell field is always present in the cell switch command.

Note: If scenarios 1 and 3 are agreed to be supported in R18 LTM other solutions may be considered.

Agreement

Send an LS to RAN2,3,4 on the RAN1 agreements in this meeting

All agreements in AI 9.10.1 and 9.10.2 in RAN1#112bis-e are included
The following contents are included in the LS

RAN1 has made the following agreement in RAN1#112bis-e

Adopt Alt.2 for beam indication of target cell(s) and TCI state activation for candidate cell(s) (if supported) ,

Alt. 1: By indicating RS identifier, i.e. mapping between RS identifier and Rel-17 unified TCI state is done by a UE
Alt. 2: By indicating Rel-17 TCI state index

This agreement implies that the source cell must be provided with information so that the source cell can send a Rel-17 TCI state index of the target/candidate cell(s) to the UE even when source cell and target/candidate cell(s) belong to different DUs. RAN1 respectfully asks RAN3 to perform any necessary specification work to support this functionality.

R1-2304275 DRAFT LS on beam indication of target cell(s) and time gap between a PDCCH order and the corresponding PRACH transmission for LTM Fujitsu, MediaTek, CATT

Decision: As per email decision posted on April 28th, the draft LS R1-2304275 is endorsed in principle. Final LS is approved in R1-2304276.

R1-2304274 Final FL summary on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

9.10.22 Timing advance management to reduce latency

R1-2302316 On TA acquisition schemes of UE based RACH-less and early RACH with RAR FUTUREWEI

R1-2302369 Timing advance management to reduce latency Huawei, HiSilicon

R1-2302414 Timing advance management for L1/L2 Mobility Ericsson

R1-2302424 Enhancements on TA management to reduce latency ZTE

R1-2302505 Discussion on TA management for L1/L2 mobility vivo

R1-2302569 Discussions on Timing Advance Management OPPO

R1-2302620 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2302731 Timing advancement management for L1L2 mobility Lenovo

R1-2302814 On Timing Advance Management Intel Corporation

R1-2302831 Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2302869 Discussion on time advance management to reduce latency CATT

R1-2302967 Discussion on Timing advance management xiaomi

R1-2303083 Enhancements on TA management for mobility LG Electronics

R1-2303149 Candidate cell TA acquisition for NR L1/L2 mobility enhancement Samsung

R1-2303254 Discussion on timing advance management to reduce latency CMCC

R1-2303260 Discussion on Timing advance management to reduce latency CAICT

R1-2303290 Discussion on Timing advance management to reduce latency KDDI Corporation

R1-2303362 UL Timing management to reduce handover latency MediaTek Inc.

R1-2303381 Discussion on TA management for L1/L2 mobility Transsion Holdings

R1-2303456 Discussion on timing advance management to reduce latency InterDigital, Inc.

R1-2303504 Timing advance management for L1/L2 Mobility Apple

R1-2303519 Discussion on timing advance management to reduce latency Google

R1-2303611 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2303728 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2303782 Discussion on TA management to reduce latency ITRI

[112bis-e-R18-Mobility-02] – Xin (CATT)

Email discussion on TA management by April 26th

- Check points: April 21, April 26

R1-2303984 Moderator summary on Timing advance management for LTM: Round 1 Moderator (CATT)

From April 17th GTW session

Agreement

For PDCCH ordered-RACH, if reception of RAR is not configured, UE autonomous re-transmission of PRACH is not allowed, regardless of the configuration of PreambleTransMax.

Agreement

When reception of RAR is configured, support RAR is received from serving cell at least in intra-DU case.

R1-2304060 Moderator summary on Timing advance management for LTM: Round 2 Moderator (CATT)

From April 19th GTW session

Agreement

When reception of RAR is configured, support RAR is received from serving cell in inter-DU case.

· FFS: RA response window related issues

Agreement

For PDCCH ordered RACH mechanism in R18 LTM, when reception of RAR is configured,

· the UE stores(remembers/maintains/handles) a TA for at least one candidate cell,

· storing(remembering/maintaining/handling) corresponding TAs for more than one candidate cell is up to UE capability,

o detailed number of candidate cell is up to UE capability.

R1-2304069 Moderator summary on Timing advance management for LTM: Round 3 Moderator (CATT)

From April 21st GTW session

Agreement

For PDCCH-order based PRACH for candidate cell study the following issues:

· whether/how prioritizations for transmission power reduction for a PRACH transmission to a LTM candidate cell is performed

· whether/how prioritizations for prioritization of a PARCH transmission to a LTM candidate cell compared to an overlapped (in time and frequency) serving cell UL transmission

R1-2304135 Moderator summary on Timing advance management for LTM: Round 4 Moderator (CATT)

From April 25th GTW session

Agreement

For PDCCH ordered-RACH, if reception of RAR is not configured

Whether power ramping is performed or not is determined from PDCCH order

If power ramping is performed,

whether PRACH is an initial transmission or retransmission is explicitly indicated in PDCCH order (FFS exact indication mechanism)
power ramping-up value is configured

else, the power should be determined by open-loop power control

Agreement

Send LS to RAN4 with the following info

RAN1 discussed the time gap between a PDCCH order and the corresponding PRACH transmission for LTM.
RAN1 believes that this will require that the time gap is increased at least for the following scenario

For PDCCH-order based PRACH on a candidate cell that is not a current serving cell with PUCCH/PUSCH or inter-frequency with the current serving cell

RAN1 relies on RAN4 to verify the need for the above additional latency and, if so, the corresponding value is needed
RAN1 relies on RAN4 to investigate any impact/interruption on UL Tx of serving cell due to the PRACH Tx on a candidate cell that is not a current serving cell with PUCCH/PUSCH
RAN1 relies on RAN4 to verify the need for any update is required to Δ_{BWPSwitching,}Δ_Delay if so, the corresponding values and whether UE capability is needed
Potential RAN1 spec update will be based on RAN4’s feedback.

LS: See the approved LS in R1-2304276 under 9.10.1.

RAN1#113

9.10 Further NR mobility enhancements

Please refer to RP-223520 for detailed scope of the WI on further NR mobility enhancements.

R1-2306147 Session notes for 9.10 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

[113-R18-Mobility] – Yosuke (Fujitsu)

Email discussion on mobility enhancements

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2306258 DRAFT LS on beam application time, contents of cell switch command, TCI state activation and UE based TA measurement for LTM Fujitsu, MediaTek, CATT

Decision: The draft LS is endorsed. Final LS is approved in R1-2306259.

9.10.1 L1 enhancements for inter-cell beam management

R1-2304352 L1 enhancements for inter-cell beam management FUTUREWEI

R1-2304399 L1 enhancements for inter-cell beam management ZTE

R1-2304498 Discussion on L1 enhancements for L1/L2 mobility vivo

R1-2304576 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2304588 FL plan on L1 enhancements for LTM at RAN1#113 Moderator (Fujitsu, MediaTek)

R1-2304659 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2304712 Further discussion on L1 enhancements for inter-cell beam management CATT

R1-2304774 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2304785 L1 enhancements to inter-cell beam management Ericsson

R1-2304823 L1 Enhancements for Inter-cell Beam Management Intel Corporation

R1-2304880 Discussion on L1 enhancements for inter-cell beam management xiaomi

R1-2304957 L1 enhancements for inter-cell beam management Lenovo

R1-2305007 L1 enhancements for inter-cell beam management KDDI Corporation

R1-2305010 Discussion on L1 enhancements for inter-cell beam management Google

R1-2305050 L1 enhancements for inter-cell beam management Sony

R1-2305072 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2305112 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2305156 Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2305263 L1 enhancements to inter-cell beam management Apple

R1-2305302 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2305356 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2305418 Discussions on Inter-cell beam management enhancement OPPO

R1-2305480 Discussion on multi-TA indication for LTM ASUSTEK COMPUTER

R1-2305533 On L1 enhancements for inter-cell beam management Samsung

R1-2305613 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2305667 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2305693 Discussion on L1 enhancements for L1L2-triggered mobility Panasonic

R1-2305712 Discussion on measurement enhancement of L1L2 triggered mobility Transsion Holdings

R1-2305783 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2305856 Discussion on L1 enhancements for inter-cell beam management InterDigital, Inc.

R1-2305128 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Tuesday session

Working Assumption

· For the beam selection for SSB based L1-RSRP measurement report,

o For the value of M, L

§ the RRC configured candidate values are:

· M = 1, 2, 3, 4

· L = [1], 2, 3, 4

§ Note: the maximum value of M*L and combination of M and L is up to UE capability

R1-2305130 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Wednesday session

Conclusion

There is no consensus to support the following procedures prior to the reception of L1/L2 cell switch command aiming at the reduction of handover delay/interruption in Rel-18 LTM

· CSI acquisition for candidate before reception of cell switch command

Note: At least for the candidate cells which are current serving cells, the CSI acquisition prior to cell switch command will be supported.

Conclusion

There is no consensus to introduce additional mechanism to support the following procedures prior to and joint with the reception of L1/L2 cell switch command aiming at the reduction of handover delay/interruption in Rel-18 LTM

· TRS tracking for candidate cells

FFS: Whether/How the QCL reference information of TCI states of the candidate cell should be mapped to the source SSB.

Note: At least for the candidate cells which are current serving cells, TRS tracking prior to cell switch command is supported.

R1-2306167 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Thursday session

Conclusion

For R18 LTM, in order to activate multiple joint TCI state or/and pair of (DL/UL) TCI states for candidate cell case, do not support TCI state activation together with beam indication of the candidate cell in the same MAC-CE message.

· FFS: UE assumption on the active TCI states other than the indicated TCI state after the reception of the cell switch command.

Agreement

A UE can be indicated and activated a single joint TCI state or a pair of UL/DL TCI state in the cell switch command.

Agreement

For the configuration of SSB based L1-RSRP measurement,

· periodicity of SSB, SSB position in burst are provided as time domain information for intra- and inter- frequency

Agreement

· Each TCI state included up to 2 qcl-types and each qcl-type source RS in a QCL-Info of the TCI state is provided at least based on the RS configuration for LTM

o FFS: other RS index outside measurement RS configuration for LTM

o FFS: Additional contents of TCI states for LTM

R1-2306168 FL summary 4 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Friday session

Agreement

For TCI state activation for candidate cell(s) before the cell switch command,

· MAC CE is used and the details of MAC-CE for TCI state activation for LTM is up to RAN2

· Further study if PDCCH order for candidate cell(s) can be used

Agreement

For the beam application time for Rel-18 LTM,

· Beam application time is supported, and starts after the last symbol of the PUCCH or PUSCH carrying the HARQ-ACK for the PDSCH which carries MAC-CE containing cell switch command with the beam indication for the target cell(s)

o FFS: reference SCS, i.e. serving cell and/or target cell

· At least the following components are further studied to define the beam application time

o Whether TCI state activation is received before/together with cell switch command

o Legacy values, i.e. and BeamAppTime-r17

o RF retuning time when inter-frequency switch is performed, which is up to RAN4

o Whether the target cell is one of the current serving cells

Cell switching time, which is defined by RAN2 and RAN4, may or may not include the potential components of beam application time above.

Send an LS to RAN2 and RAN4 to ask their feedback.

Agreement

For the beam selection for SSB based L1-RSRP measurement report,

· the inclusion of current SpCell in the L1 measurement report is configurable.

o New UE capability(ies) are introduced and details can be discussed in UE feature.

Agreement

Send an LS to RAN2,3,4 on the RAN1 agreements in this meeting

· All agreements in AI 9.10.1 and 9.10.2 in RAN1#113 are included

· The following information to RAN2 is included:

o Whether C-RNTI that is to be used by target cell needs to be included within the MAC-CE containing cell switch command will be left to RAN2 decision.

o It will be left to RAN2 decision whether the following fields are always present or not in the cell switch command:

§ TA related information

Conclusion

For the beam selection for SSB based L1-RSRP measurement report, except SpCell is configured to be included,

· the selection of cells for the L1 measurement report is up to UE implementation.

· the selection of beams per cell for the L1 measurement report is the same as legacy behaviour.

Conclusion

No consensus to introduce UE/event triggered report for L1 measurement results for LTM in Rel-18.

Final summary in R1-2306260.

9.10.22 Timing advance management to reduce latency

R1-2304353 Discussion on UE based RACH-less TA determination FUTUREWEI

R1-2304400 Enhancements on TA management to reduce latency ZTE

R1-2304499 Discussion on TA management for L1/L2 mobility vivo

R1-2304577 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2304660 Timing advance management to reduce latency Huawei, HiSilicon

R1-2304713 Discussion on time advance management to reduce latency CATT

R1-2304786 Timing advance management for L1/L2 Mobility Ericsson

R1-2304881 Discussion on Timing advance management xiaomi

R1-2304958 Timing advancement management for L1L2 mobility Lenovo

R1-2305011 Discussion on timing advance management to reduce latency Google

R1-2305023 Discussion on timing advance management to reduce latency CAICT

R1-2305113 Discussion on timing advance management to reduce latency CMCC

R1-2305157 Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2305264 Timing advance management for L1/L2 triggered mobility Apple

R1-2305303 Enhancements on TA management for mobility LG Electronics

R1-2305357 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2305419 Discussions on Timing Advance Management OPPO

R1-2305962 Candidate cell TA acquisition for NR L1/L2 mobility enhancement Samsung (rev of R1-2305534)

R1-2305614 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2305645 UL Timing management to reduce handover latency MediaTek Inc.

R1-2305713 Discussion on TA management for L1/L2 mobility Transsion Holdings

R1-2305775 Discussion on TA management for mobility enhancement ITRI

R1-2305784 Discussion on TA management for LTM FGI

R1-2305857 Discussion on timing advance management InterDigital, Inc.

R1-2306035 Moderator summary on Timing advance management for LTM: Round 1 Moderator (CATT)

From Tuesday session

Agreement

Confirm the following Working Assumption, and sent LS to RAN4 to clarify the feasibility of supporting this mechanism

Working Assumption

From RAN 1 perspective, UE-based TA measurement (UE derives TA based on Rx timing difference between current serving cell and candidate cell as well as TA value for the current serving cell) is supported.

· Corresponding UE capability is to be introduced to support UE-based TA measurement

· For a UE reports support of this capability, configuration of UE-based TA measurement is supported

· FFS: other impacts on RAN1 spec

Agreement

From RAN 1 perspective, without performing PDCCH-ordered RACH for candidate cell(s), RACH-less mechanism can be supported by indicating TA value of target cell as TA=0 or keeping the same value as source cell in cell switch command.

· Note 1: this doesn’t mean to preclude TA values other than 0 and the same value as source cell in cell switch command for PDCCH-ordered RACH when RAR is not configured for the PDCCH order.

· Note 2: The feasibility and signalling can be further concluded by RAN2

Agreement

For PDCCH order based PRACH to candidate cell, the candidate cell SSB indicated in the PDCCH order serves as the path loss RS for PRACH Tx power determination.

Agreement

On the determination of the PRACH transmission power when reception of RAR is not configured, a [1-bit] field in PDCCH order explicitly indicating initial transmission or retransmission of PRACH is supported.

R1-2306123 Moderator summary on Timing advance management for LTM: Round 2 Moderator (CATT)

From Wednesday session

Note:

From RAN1 perspective, when reception of RAR is configured, there may have 4 alternatives to determine the random access response window

· Alt1: Postpone the starting point of the random access response window

· Alt2: Extend the length of the random access response window

· Alt3: Length and offset of the starting point of RAR window can be configured by RRC

· Alt4: if MAC CE is used to carry TA and PDCCH is scrambled by C-RNTI in USS, RAR window is not needed

[Note: the random access response window for candidate cell(s) is separately configured from the normal RAR window.]

Note:

In addition to TA, when reception of RAR is configured, RAN1 discussed the following alternatives:

· Alt 1: when there is only one ongoing RACH procedure at each time, the identification of candidate cell is not needed.

· Alt 2: when more than one RACH procedures are allowed at each time, the identification of candidate cell is contained in RAR.

R1-2306158 Moderator summary on Timing advance management for LTM: Round 3 Moderator (CATT)

From Thursday session

Agreement

On the determination of the PRACH transmission power when reception of RAR is not configured, a 1-bit field in PDCCH order explicitly indicating initial transmission or retransmission of PRACH, FFS

· UE will increase the power with the value of power ramping configuration if it is indicated as re-transmission, unless the max allowed power is achieved

· whether/how to reset the counter

Agreement

· For PDCCH-order based PRACH for candidate cell, If UE capability does not support simultaneous/parallel transmissions, when the PRACH transmission to a candidate cell other than current serving cell(including any interruption due to processing time to build the PRACH transmission, carrier or/and BWP switching time if any, UL or DL RF retuning time if any, additional preparation time if any) happen to overlap over one or more symbols or have a time gap below a certain threshold (e.g., N symbols, FFS: the value of N) with following UL transmission to one of the serving cells

o PRACH transmission

o PUCCH/PUSCH transmission carrying HARQ-ACK, SR, P/SP CSI, aperiodic CSI

o SRS transmission

o Any other PUCCH/PUSCH transmission

· Down-select the UE behavior in this case

o Alt 1: Dropping rule is needed

o Alt 2: up to UE implementation

RAN1#114

9.10 Further NR mobility enhancements

Please refer to RP-231475 for detailed scope of the WI on further NR mobility enhancements. Rapporteur to provide initial input on higher layer signalling under agenda item 9.10. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items. Consider additional RAN agreements from RAN#100 (RP-231475, proposals 1 – 6).

R1-2308548 Session notes for 9.10 (Further NR mobility enhancements) Ad-Hoc Chair (CMCC)

Endorsed and contents incorporated below.

[114-R18-Mobility] – Yosuke (Fujitsu)

Email discussion on mobility enhancements

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2308663 Rel-18 RRC parameters for NR mobility enhancement WI for RAN1 114 Rapporteur (Apple)

9.10.1 L1 enhancements for inter-cell beam management

From AI 5

R1-2306386 LS on L1 measurements for LTM RAN2, Ericsson

Decision: Discussion on response LS to be handled in agenda item 9.10. To be moderated by Claes (Ericsson).

R1-2308447 Draft reply LS on L1 measurements for LTM Moderator (Ericsson)

Agreement from Wednesday session

Draft LS 2308447 is endorsed in principle by revising

According to RAN1’s agreement in RAN1#112bis meeting, M x L beams are reported in a single report instance. Beam selection is performed across the L cells from configured cells, i.e., M beams for each of the L cells. According to the conclusion from RAN1#113, how to select the L cells is up to UE. Therefore, UE reports one or a subset of measured LTM candidate cell(s) in a report (option b in RAN2’s agreement). If L cells are configured for measurement, the UE would report all L configured cells.

According to RAN1’s agreement in RAN1#112bis meeting, M x L beams are reported in a single report instance. UE reports beams of L cells from configured cells with M beams for each of the L cells. According to the conclusion from RAN1#113, how to select the L cells is up to UE.

Final LS is approved in R1-2308465.

R1-2306425 L1 enhancements for inter-cell beam management FUTUREWEI

R1-2306518 L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2306578 Discussions on L1 enhancements for inter-cell beam management Ruijie Network Co. Ltd

R1-2306601 L1 enhancements to inter-cell beam management Ericsson

R1-2306616 L1 enhancements for inter-cell beam management ZTE

R1-2306663 Discussion on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2306767 Discussion on L1 enhancement for LTM vivo

R1-2306812 Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2306938 L1 enhancements for inter-cell beam management Lenovo

R1-2306947 Discussion on L1 enhancements for inter-cell beam management NEC

R1-2307018 Enhancements on inter-cell beam management for mobility LG Electronics

R1-2307060 Remaining issues on L1 enhancements for inter-cell beam management CATT

R1-2307164 Views on L1 enhancements for inter-cell beam management Fujitsu

R1-2307213 Discussion on L1 enhancements for inter-cell beam management CMCC

R1-2307297 L1 Enhancements for Inter-Cell Beam Management Apple

R1-2307335 FL plan on L1 enhancements for LTM at RAN1#114 Moderator (Fujitsu, MediaTek) (rev of R1-2306405)

R1-2307354 Discussion on L1 enhancements for inter-cell beam management in LTM xiaomi

R1-2307403 L1 enhancements for inter-cell beam management KDDI Corporation

R1-2307488 Discussion on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2307526 Discussions on Inter-cell beam management enhancement OPPO

R1-2307697 On L1 enhancements for inter-cell beam management Samsung

R1-2307767 Discussion on measurement enhancement of L1L2 triggered mobility Transsion Holdings

R1-2307780 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2307839 Remaining issues on L1 triggered mobility InterDigital, Inc.

R1-2307850 Discussion on L1 enhancements for inter-cell beam management Google

R1-2307946 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2308084 L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2307408 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Tuesday session

Agreement

Confirm the following working assumption achieved in RAN-112bis-e.

Agreement

On top the confirmed working assumption, on the presence of beam indication within cell switch command, at least for scenario 2 following is supported:

· A field to indicate 1 joint or 1 pair of UL and DL unified TCI State index for the target cell field is always present in the cell switch command.

· FFS UE behaviour for the beam indication field for the RACH-based handover scenario after cell switch command

Conclusion

In R18 LTM, there is no consensus to support triggering of aperiodic SRS transmission to the target cell in the cell switch command.

Agreement

In R18 LTM, on the QCL source of the TCI state before/during the cell switch command,

SSB or TRS can be configured in a TCI state for the candidate cell(s) before/during cell switch command.

Whether the TRS can be used for the candidate cell(s) before/during cell switch command is up to UE capability.

Agreement

In Rel-18 LTM, only CD-SSB is supported for L1 intra- and inter-frequency measurement.

R1-2307409 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Wednesday session

Agreement

· For the beam selection for SSB based L1-RSRP measurement report,

o For the value of M, L

§ the RRC configured candidate values are:

· M = 1, 2, 3, 4

· L = 1, 2, 3, 4

§ Note: the maximum value of M*L and combination of M and L is up to UE capability

· Note: the common understanding is that L=1 with configuration of inclusion of serving cell is not a typical case.

· No need to confirm the corresponding working assumption (made in RAN1#113).

R1-2307410 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

R1-2308592 FL summary 4 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Friday session

Agreement

· Send an LS to RAN2,3,4 on the RAN1 agreements in this meeting

o All agreements in AI 9.10.1 and 9.10.2 in RAN1#114 are included

R1-2308624 DRAFT LS on L1 measurement and TA management for LTM Fujitsu, MediaTek, CATT

Decision: The draft LS R1-2308624 is endorsed in principle. Final LS is approved in R1-2308625.

Agreement

TCI state activation by MAC CE before cell switch command for one or more than one candidate cells is allowed.

Agreement

Absolute value and differential values are used for L1-RSRP reporting:

· For absolute L1-RSRP, the L1-RSRP value is quantized to a 7-bit value in the range [-140, -44] dBm with 1dB step size.

· For differential L1-RSRP, the L1-RSRP value is quantized to a 4-bit value where the differential L1-RSRP value is computed with 2 dB step size from reference L1-RSRP value.

Agreement

SSBRI among configured candidate cells is included for each L1-RSRP report

· The bit size of SSBRI is where is the number of configured SSBs in the corresponding resource set for the report

· The following format is used for reporting

CSI report number	CSI fields
CSI report #n	SSBRI #1 as in Table 6.3.1.1.2-6, if reported
	SSBRI #2 as in Table 6.3.1.1.2-6, if reported
	:
	SSBRI #L*M as in Table 6.3.1.1.2-6, if reported
	RSRP #1 as in Table 6.3.1.1.2-6, if reported
	Differential RSRP #2 as in Table 6.3.1.1.2-6, if reported
	:
	Differential RSRP #L*M as in Table 6.3.1.1.2-6, if reported

Final summary in R1-2308593.

9.10.22 Timing advance management to reduce latency

R1-2306426 UE based RACH-less TA determination for inter-cell LTM FUTUREWEI

R1-2306519 Timing advance management to reduce latency Huawei, HiSilicon

R1-2306579 Discussions on timing advance management to reduce latency Ruijie Network Co. Ltd

R1-2306602 Timing advance management for L1/L2 Mobility Ericsson

R1-2306617 Enhancements on TA management to reduce latency ZTE

R1-2306664 Discussion on timing advance management to reduce latency Spreadtrum Communications

R1-2306768 Discussion on TA management for LTM vivo

R1-2306813 Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2306939 Timing advancement management for L1L2 mobility Lenovo

R1-2307019 Enhancements on TA management for mobility LG Electronics

R1-2307061 Remaining issues on TA management to reduce latency CATT

R1-2307214 Discussion on timing advance management to reduce latency CMCC

R1-2307298 Timing advance management for L1/L2 Mobility Apple

R1-2307355 Discussion on Timing advance management xiaomi

R1-2307489 Timing advance enhancement for inter-cell mobility NTT DOCOMO, INC.

R1-2307527 Discussions on Timing Advance Management OPPO

R1-2307698 Candidate cell TA acquisition for NR L1/L2 mobility enhancement Samsung

R1-2307752 Discussion on TA management for mobility enhancements ETRI

R1-2307768 Discussion on TA management for L1/L2 mobility Transsion Holdings

R1-2307840 Discussion on the remaining details for timing advance management InterDigital, Inc.

R1-2307851 Discussion on timing advance management to reduce latency Google

R1-2307892 Discussion on TA management to reduce latency ITRI

R1-2307947 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2308012 Discussion on TA management to reduce latency CAICT

R1-2308073 UL Timing management to reduce handover latency MediaTek Inc.

R1-2308242 Moderator summary on Timing advance management for LTM: Round 1 Moderator (CATT)

From Tuesday session

Agreement

For the power control of PDCCH-ordered CFRA in LTM, the UE can maintain only one power ramping counter.

Agreement

For the power control of PDCCH-ordered CFRA in LTM, power-ramping counter is reset at least when UE receives a PDCCH order indicating the initial transmission of PRACH.

Agreement

when a PDCCH order is sent for a candidate cell,

· The bit size of N in DCI format 1_0 for cell indicator is determined by the number (e.g., C) of configured candidate cells with RACH configuration provided for early TA acquisition, down-select one from the following alternatives.

o Alt 1: N=

o Alt 2: N= (update the equation with (C+1))

§ The number of cells used to calculate the bit width is the number of candidate cells with RACH configuration provided for early TA acquisition + 1 (serving cell)

R1-2308405 Moderator summary on Timing advance management for LTM: Round 2 Moderator (CATT)

From Wednesday session

Agreement

For the power control of PDCCH-ordered CFRA in LTM,

· When a UE receives a PDCCH order indicating a re-transmission of PRACH with the same associated SSB and same candidate cell as the previous PRACH, the counter is increased by 1.

· In addition to case 1, power-ramping counter is reset in the following cases:

o Case 2: The candidate cell indicated in the PDCCH order, indicating retransmission, is different from that indicated in the last PDCCH order.

Note: the initial counter is 0 before receiving any PDCCH order.

R1-2308468 Moderator summary on Timing advance management for LTM: Round 3 Moderator (CATT)

From Thursday session

Agreement

when a PDCCH order is sent for a candidate cell,

The bit size of N in DCI format 1_0 for cell indicator is determined by the number (e.g., C) of configured candidate cells with RACH configuration provided for early TA acquisition, the following alternative is supported:

Alt 2: N=

The number of cells used to calculate the bit width is the number of candidate cells with RACH configuration provided for early TA acquisition + 1 (serving cell)

Agreement

When the UE does not support simultaneous/parallel transmissions of PRACH in candidate cell and UL channels and signals in serving cell, support

· serving cell UL TX is dropped.

Agreement

If the UE supports simultaneous/parallel transmissions of PRACH in candidate cell and UL channels and signals in serving cell in the same frequency range, support:

· A PRACH transmission to a LTM candidate cell has the highest priority for power allocation.

Note: up to UE whether performs power scale-down or drop of UL transmission with lower priority when UL transmission power is insufficient.

RAN1#114-bis

8.7 Maintenance on Further NR Mobility Enhancements

R1-2310545 Session notes for 8.7 (Maintenance on further NR mobility enhancements) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[114bis-R18-Mobility] – Yosuke (Fujitsu)

Email discussion on mobility enhancements

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2310676 Rel-18 RRC parameters for NR mobility enhancement WI for RAN1 114bis Rapporteur (Apple)

8.7.1 L1 enhancements for inter-cell beam management

R1-2308889 Maintenance of L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2308934 Discussion on remaining issues of L1 enhancements for inter-cell beam management FUTUREWEI

R1-2308993 Remaining issues on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2309020 Maintenance on L1 enhancements for inter-cell beam management ZTE

R1-2309083 L1 enhancements for L1/L2-triggered mobility vivo

R1-2309126 FL plan on L1 enhancements for LTM at RAN1#114b-bis Moderator (Fujitsu, MediaTek) (rev of R1-2309109)

R1-2309161 Maintenance of L1 enhancements to inter-cell beam management Ericsson

R1-2309216 FL plan on L1 enhancements for LTM at RAN1#114b-bis Moderator (Fujitsu, MediaTek)

R1-2309295 Remaining issues on L1 enhancements for inter-cell beam management NEC

R1-2309322 Remaining issues on L1 enhancements for inter-cell beam management Lenovo

R1-2309383 Remaining details on L1 enhancements for inter-cell beam management Samsung

R1-2309464 Discussion on remaining issue about L1 enhancements for LTM xiaomi

R1-2309534 Maintenance on L1 enhancements for inter-cell beam management CATT

R1-2309579 Remaining Issues of Inter-cell beam management enhancement OPPO

R1-2309649 Remaining issues on L1 enhancements for inter-cell beam management Fujitsu

R1-2309679 Remaining issues on L1 enhancements for inter-cell beam management CMCC

R1-2309727 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2309733 Remaining Issues on Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2309739 Remaining issues on L1 enhancement for LTM Panasonic

R1-2309786 Discussion on L1 enhancements for inter-cell beam management Google

R1-2309841 L1 enhancements to inter-cell beam management Apple

R1-2309876 Remaining issues on L1 enhancements for inter-cell beam management KDDI Corporation

R1-2309953 Remaining issues on L1 enhancements InterDigital, Inc.

R1-2309982 Remaining issues on L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2310040 Remaining issues on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2310149 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2309110 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Tuesday session

Conclusion

For the necessity of Padding bit in the L1 measurement report for LTM in the case where the report size is less than 12-bits, no enhancements are specified in the spec.

Conclusion

No specific specification change in RAN1 is pursued for scenario 3 for LTM (i.e. Beam indication after cell switch command).

R1-2309111 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

Presented in Wednesday session.

R1-2310642 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

From Friday session

Agreement

For the LTM L1 measurement report,

· When a UE is configured is configured with SpCellInclusion, the SpCell measurements are the entries in the LTM-CSI-SSB-ResourceSet where the PCI and frequency information [SSB frequency/ARFCN] of the candidate cell is equal to the PCI and frequency information [SSB frequency/ARFCN] of the current SpCell.

R1-2310643 Final FL summary on L1 enhancements for inter-cell beam management Moderator (Fujitsu, MediaTek)

8.7.22 Timing advance management to reduce latency

R1-2308890 Maintenance of timing advance management to reduce latency Huawei, HiSilicon

R1-2308935 Network assisted UE TA determination with high accuracy FUTUREWEI

R1-2308994 Remaining issues on timing advance management to reduce latency Spreadtrum Communications

R1-2309021 Maintenance on TA management to reduce latency ZTE

R1-2309084 TA management for L1/L2-triggered mobility vivo

R1-2309162 Maintenance of TA management for LTM Ericsson

R1-2309323 Remaining issue of timing advancement management for L1L2 mobility Lenovo

R1-2309384 Remaining issues on candidate cell TA management for NR L1/L2 mobility enhancement Samsung

R1-2309535 Remaining issues on TA management to reduce latency CATT

R1-2309580 Remaining Issues of Timing Advance Management OPPO

R1-2309680 Remaining issues on timing advance management to reduce latency CMCC

R1-2309728 Remaining issues on TA management for LTM FGI

R1-2309734 Remaining Issues on Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2309787 Discussion on timing advance management to reduce latency Google

R1-2309842 Timing advance management for L1/L2 Mobility Apple

R1-2309954 Remaining details on timing advance management InterDigital, Inc.

R1-2310041 Remaining issues on TA enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2310070 Discussion on TA management to reduce latency CAICT

R1-2310150 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2310360 Moderator summary on timing advance management for LTM: Round 1 Moderator (CATT)

From Tuesday session

Agreement

Remove the bracket [] and add the following two child IEs into RRC parameters list for LTM to determine the frequency location of PRACH resource for early UL sync procedure:

#	RAN2 parent IE	Parameter name in the spec	New or existing?	Description	Value Range
1	ltm-EarlyUlSyncConfig-r18	EarlyUlSyncConfig-r18	new	Configuration used by the UE to perform the early UL synchronization procedure.	SEQUENCE { FrequencyInfoUL [BWP-genericParameters] rach-ConfigGeneric, ssb-perRACH-Occasion, prach-RootSequenceIndex }
2	EarlyUlSyncConfig-r18	BWP-genericParameters	new	configure the common parameters of an uplink BWP of candidate cell	BWP
3	BWP-genericParameters	BWP	Existing	Configure the common parameters of an uplink BWP of candidate cell	SEQUENCE { locationAndBandwidth, subcarrierSpacing, cyclicPrefix }

Agreement

Introduce new components of T_SSB and ∆_{RF/BB_preparation} in the time gap between the last symbol of the PDCCH order reception and the first symbol of the PRACH transmission in RAN1 formula according to the RAN4 reply LS [R4-2314454].

· BWP switching related delay (∆_BWPSwitching)is not needed or equals to zero for LTM early TA acquisition.

· The corresponding TP is to be discussed in RAN1 #114-bis.

Friday comment: RAN1 failed to discuss the TP as stated in the second sub-bullet - therefore such discussion should take place in the next meeting.

R1-2310441 Moderator summary on timing advance management for LTM: Round 2 Moderator (CATT)

From Wednesday session

Agreement

The bit field codepoint ‘0’ of cell indicator field in PDCCH order indicates PRACH for current serving cell, the rest bit field codepoints are mapped to candidate cells configured with EarlyUlSyncConfig-r18.

· One-to-one mapping between bit field codepoint from 1 to C to candidate cell IDs in an ascending order.

Conclusion

TA acquisition of candidate cell(s) before cell switch command is received in L1/L2 based mobility is supported when the candidate cell(s) is deactivated SCell(s).

R1-2310506 Moderator summary on timing advance management for LTM: Round 3 Moderator (CATT)

RAN1#115

8.7 Maintenance on Further NR Mobility Enhancements

R1-2312506 Session notes for 8.7 (Maintenance on further NR mobility enhancements) Ad-Hoc Chair (Huawei)

Friday decision: The session notes are endorsed and contents reflected below.

[115-R18-Mobility] – Yosuke (Fujitsu)

Email discussion on mobility enhancements

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2312391 Summary of RRC parameters for NR mobility enhancement WI for RAN1 115 meeting Rapporteur (Apple)

From Tuesday session

Agreement

· Agree the following RRC parameter for CSI related to LTM CSI report

#	RAN2 parent IE	Parameter name in the spec	New or existing?	Description	Value Range
1	reportConfigType	semiPersistentOnPUSCH	new	Describes the properties of semipersistent on PUSCH LTM report	SEQUENCE { reportSlotConfig-r18 reportSlotOffsetList-r18 reportSlotOffsetListDCI-0-2-r18 reportSlotOffsetListDCI-0-1-r18 p0alpha },
2	reportConfigType	aperiodic	new	Describes the properties of aperiodic LTM report	SEQUENCE { reportSlotOffsetList-r18 reportSlotOffsetListDCI-0-2-r18 reportSlotOffsetListDCI-0-1-r18 }
3	semiPersistentOnPUSCH, aperiodic	reportSlotOffsetList-r18, reportSlotOffsetListDCI-0-2-r18, reportSlotOffsetListDCI-0-1-r18	new	Timing offset Y for semi persistent reporting using PUSCH and for aperiodic reporting	SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128)

Agreement

RAN2 parent IE

Parameter name in the spec

New or existing?

Description

Value Range

EarlyUlSyncConfig-r18

LTM_PRACH_subcarrierSpacing

new

Indicates subcarrier spacing of PRACH for LTM.

ssbSubcarrierSpacing

Only the following values are applicable depending on the used frequency:

FR1: 15 or 30 kHz

FR2-1: 60 or 120 kHz

FR2-2: 120, 480, or 960 kHz

Agreement

· Agree at least the following RRC parameter for ‘LTM-Candidate-Tci-State’ configuration

#	RAN2 parent IE	Parameter name in the spec	New or existing?	Description	Value Range
1	LTM-Candidate-Tci-States -r18	qcl-Type1, qcl-Type2,	new	QCL information for the TCI state	LTM-QCL-info-r18
2	qcl-Type1, qcl-Type2,	LTM-QCL-info-r18	new	QCL type	SEQUENCE { ReferenceSignal, qcl-Type, }
3	ReferenceSignal	ssb	existing	This field is used to indicate the SS/PBCH index of the SS/PBCH block corresponding to the LTM-TCI-state of the candidate cell.	SSB-index
4	LTM-QCL-info-r18	qcl-Type	existing	QCL type as specified in TS 38.214 [19] clause 5.1.5	ENUMERATED {typeA, typeB, typeC, typeD}

· Agree at least the following RRC parameter for ‘UL LTM-TCI-State’ configuration

RAN2 parent IE

Parameter name in the spec

New or existing?

Description

Value Range

ltm-ul-TCI-ToAddModList

LTM-Candidate-TCI-UL-State-r18

new

Indicates the TCI-state information for UL transmission of candidate cell.

SEQUENCE {

LTM-TCI-UL-StateId,

ReferenceSignal,

}

LTM-Candidate-TCI-UL-State-r18

LTM-TCI-UL-StateId

new

Identify one CandidateTCI-UL-State configuration

INTEGER (0.. -maxNrofCandidateTCI-UL-States)

R1-2312542 Summary#2 of RRC parameters for NR mobility enhancement WI Rapporteur (Apple)

From Wednesday session

Agreement

· Agree the following RRC parameter for ‘Pathloss Reference’ configuration

#	RAN2 parent IE	Parameter name in the spec	New or existing?	Description	Value Range
1	LTM-Config-r18	LTM-Candidate-r18	new		SEQUENCE { LTM-CandidateId-r18, LTM-SSB-Config-r18, LTM-dl-OrJointTCI-StateToAddModList, LTM-dl-OrJointTCI-StateToReleaseList-r18, LTM-ul-TCI-ToAddModList, LTM-ul-TCI-ToReleaseList-r17, pathlossReferenceRSToAddModList-r18 pathlossReferenceRSToReleaseList-r18 LTM-EarlyUlSyncConfig-r18 candidatePci-r18, }
2	LTM-Candidate-r18	pathlossReferenceRSToAddModList-r18	new	A list of Reference Signals to be used for path loss estimation for unified TCI state operation.	SEQUENCE (SIZE (1.. maxNrofLtmPathlossReferenceRSs-r18)) OF PathlossReferenceRS-r18
3	pathlossReferenceRSToAddModList-r18	PathlossReferenceRS-r18	new	To configure a Reference Signal to be used for path loss estimation for PUSCH, PUCCH and SRS for unified TCI state operation.	SEQUENCE { pathlossReferenceRS-Id-r18 referenceSignal-r18 CHOICE { ssb-Index, [csi-RS-Index], } }
4	PathlossReferenceRS-r18	ssb-Index	existing	This field is used to indicate the SS/PBCH index of the SS/PBCH block to be used for path loss estimation for PUSCH, PUCCH and SRS	SSB-Index
5	LTM-Candidate-r18	pathlossReferenceRSToReleaseList-r18	new	Indicates a list of one or more pathloss Reference Signals to be released	SEQUENCE (SIZE (1..maxNrofPathlossReferenceRSs-r17)) OF pathlossReferenceRS-Id-r18

Conclusion

Uplink power control parameters are not pre-configured inside of ‘LTM-Candidate-Tci-States-r18’ IE and ‘LTM-Candidate-TCI-UL-State-r18’ IE.

R1-2312616 Summary#3 of RRC parameters for NR mobility enhancement WI Rapporteur (Apple)

From Thursday session

Agreement

· Agree the following RRC parameter for ‘Pathloss Reference’ configuration

RAN2 parent IE

Parameter name in the spec

New or existing?

Description

Value Range

ltm-dl-OrJointTCI-StateToAddModList

LTM-Candidate-Tci-States -r18

new

associates one or two DL reference signals with a corresponding quasi-colocation (QCL) type

SEQUENCE {

LTM-tci-StateId,

qcl-Type1,

qcl-Type2,

pathlossReferenceRS-Id-r18

}

ltm-ul-TCI-ToAddModList

LTM-Candidate-TCI-UL-State-r18

new

Indicates the TCI-state information for UL transmission of candidate cell.

SEQUENCE {

LTM-tci-UL-StateId,

refereneSignal-r18,

pathlossReferenceRS-Id-r18

}

Agreement

· Agree the following RRC parameter for TRS configuration

#	RAN2 parent IE	Parameter name in the spec	New or existing?	Description	Value Range
1	LTM-Config-r18	LTM-Candidate-r18	new	This field contains necessary information for the UE for procedures about an LTM candidate cell to be executed before an LTM cell switch	LTM-CandidateId-r18, LTM-SSB-Config-r18, LTM-dl-OrJointTCI-StateToAddModList, LTM-dl-OrJointTCI-StateToReleaseList-r18, LTM-ul-TCI-ToAddModList, LTM-ul-TCI-ToReleaseList-r17, LTM-nzp-CSI-RS-ResourceToAddModList, LTM-nzp-CSI-RS-ResourceToReleaseList, LTM-nzp-CSI-RS-ResourceSetToAddModList, LTM-nzp-CSI-RS-ResourceSetToReleaseList, ….. }
2	LTM-Candidate-r18	LTM-nzp-CSI-RS-ResourceToAddModList	new	Defines a list of LTM-nzp-CSI-RS-Resources	SEQUENCE (SIZE (1..maxNrofLtmNZP-CSI-RS-Resources)) OF LTM-NZP-CSI-RS-Resource
3	LTM-Candidate-r18	LTM-nzp-CSI-RS-ResourceToReleaseList	new	List of LTM-nzp-CSI-RS-Resource to be released	SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-Resources)) OF LTM-NZP-CSI-RS-ResourceId
4	LTM-nzp-CSI-RS-ResourceToAddModList	LTM-NZP-CSI-RS-Resource	new	Configure Non-Zero-Power (NZP) CSI-RS transmitted in the cell	SEQUENCE { LTM-nzp-CSI-ResourceId, resourceMapping, powerControlOffsetSS, scramblingID, periodicityAndOffset, qcl-InfoPeriodicCSI-RS, subcarrierSpacing, absoluteFrequencyPointA, }
5	LTM-NZP-CSI-RS-Resource	LTM-nzp-CSI-ResourceId	new	Identify one LTM-NZP-CSI-RS-Resource	INTEGER (0..maxNrofLtmNZP-CSI-RS-Resources-1)
6	LTM-NZP-CSI-RS-Resource	resourceMapping	Existing	OFDM symbol location(s) in a slot and subcarrier occupancy in a PRB of the CSI-RS resource.	CSI-RS-ResourceMapping
7	LTM-NZP-CSI-RS-Resource	powerControlOffsetSS	Existing	Power offset of NZP CSI-RS RE to SSS RE	ENUMERATED{db-3, db0, db3, db6}
8	LTM-NZP-CSI-RS-Resource	scramblingID	Existing	Scrambling ID (see TS 38.214 [19], clause 5.2.2.3.1).	ScramblingId
9	LTM-NZP-CSI-RS-Resource	periodicityAndOffset	Existing	Periodicity and slot offset of CSI-RS Resource.	CSI-ResourcePeriodicityAndOffset
10	LTM-NZP-CSI-RS-Resource	qcl-InfoPeriodicCSI-RS	new	For a target periodic CSI-RS, contains a reference to one TCI-State in TCI-States for providing the QCL source and QCL type	LTM-tci-StateId
11	LTM-NZP-CSI-RS-Resource	subcarrierSpacing	Existing	Subcarrier spacing of CSI-RS.	ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240, kHz480-v1700, kHz960-v1700, spare1}
12	LTM-NZP-CSI-RS-Resource	absoluteFrequencyPointA,	Existing	This field indicates the absolute frequency position of the reference resource block (Common RB 0).	ARFCN-ValueNR
13	LTM-Candidate-r18	LTM-nzp-CSI-RS-ResourceSetToAddModList	new	defines a list of LTM-nzp-CSI-RS-ResourceSets	SEQUENCE (SIZE (1..maxNrofLtmNZP-CSI-RS-ResourceSets)) OF LTM-NZP-CSI-RS-ResourceSet
14	LTM-Candidate-r18	LTM-nzp-CSI-RS-ResourceSetToReleaseList	New	List of LTM-nzp-CSI-RS-ResourceSet to be released	SEQUENCE (SIZE (1..maxNrofLtmNZP-CSI-RS-ResourceSets)) OF NZP-CSI-RS-ResourceSetId
15	LTM-nzp-CSI-RS-ResourceSetToAddModList	LTM-NZP-CSI-RS-ResourceSet	new	Provide a set of LTM-Non-Zero-Power (NZP) CSI-RS resources for LTM operatio	SEQUENCE { LTM-nzp-CSI-ResourceSetId, LTM-nzp-CSI-RS-Resources, trs-Info, resourceType-18, }
16	LTM-NZP-CSI-RS-ResourceSet	resourceType-18	Existing	Time domain behavior of resource configuration (see TS 38.214 [19], clause 5.2.1.2).	ENUMERATED {periodic }
17	LTM-NZP-CSI-RS-ResourceSet	LTM-nzp-CSI-ResourceSetId	new	used to identify one LTM-NZP-CSI-RS-ResourceSet.	INTEGER (0..maxNrofLtmNZP-CSI-RS-ResourceSets-1)
18	LTM-NZP-CSI-RS-ResourceSet	LTM-nzp-CSI-RS-Resources	new	NZP-CSI-RS-Resources associated with this NZP-CSI-RS resource set	SEQUENCE (SIZE (1..maxNrofLtmNZP-CSI-RS-ResourcesPerSet)) OF LTM-nzp-CSI-ResourceId
19	LTM-NZP-CSI-RS-ResourceSet	trs-info	Existing	Indicates that the antenna port for all NZP-CSI-RS resources in the CSI-RS resource set is same	ENUMERATED {true}
20	LTM-QCL-info-r18	ReferenceSignal	new	Reference signal with which quasi-collocation information is provided	CHOICE{ NZP-CSI-RS-ResourceId, ssb }
21	ReferenceSignal	NZP-CSI-RS-ResourceId	new	Provide one NZP-CSI-RS-Resource.	INTEGER (0..maxNrofLtmNZP-CSI-RS-Resources-1)

· FFS on the following IE:

LTM-NZP-CSI-RS-Resource

powerControlOffset

Existing

Power offset of PDSCH RE to NZP CSI-RS RE

INTEGER (-8..15)

R1-2312679 Summary#4 of RRC parameters for NR mobility enhancement WI Rapporteur (Apple)

From Friday session

Agreement

· Add the following RRC parameter for ‘LTM-Candidate-Tci-State’ configuration:

RAN2 parent IE

Parameter name in the spec

New or existing?

Description

Value Range

LTM-nzp-CSI-RS-ResourceToAddModList

LTM-NZP-CSI-RS-Resource

new

Configure Non-Zero-Power (NZP) CSI-RS transmitted in the cell

SEQUENCE {

LTM-nzp-CSI-ResourceId,

resourceMapping,

powerControlOffsetSS,

scramblingID,

periodicityAndOffset,

qcl-InfoPeriodicCSI-RS,

subcarrierSpacing,

absoluteFrequencyPointA,

cyclicPrefix,

}

LTM-NZP-CSI-RS-Resource

cyclicPrefix

existing

Indicates whether to use the extended cyclic prefix for this LTM NZP-CSI-RS resource. If not set, the UE uses the normal cyclic prefix.

ENUMERATED { extended }

R1-2312680 RRC parameters list update #2 for NR mobility enhancement WI Rapporteur (Apple) (rev of R1-2312469)

8.7.1 L1 enhancements for inter-cell beam management

From AI 5

R1-2310809 LS on L1 measurements for LTM RAN2, Ericsson

Decision: To be handled in agenda item 8.7.1 To be moderated by Claes (Ericsson).

R1-2312442 Draft reply LS on L1 measurements in LTM Moderator (Ericsson)

Wednesday decision: The draft LS reply in R1-2312442 is endorsed (with fixing the dates of the next meetings). Final LS is approved in R1-2312443.

R1-2310830 Remaining issues of L1 enhancements for inter-cell beam management FUTUREWEI

R1-2310848 Maintenance of L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2310954 Maintenance on L1 enhancements for inter-cell beam management ZTE

R1-2312275 Maintenance of L1 enhancements to inter-cell beam management Ericsson (rev of R1-2310972)

R1-2311034 FL plan on L1 enhancements for LTM at RAN1#115 Moderator (Fujitsu)

R1-2311053 Remaining issues on L1 enhancements for inter-cell beam management Fujitsu

R1-2311105 Discussion on L1 enhancement for L1/L2-triggered Mobility vivo

R1-2311172 Remaining issues on L1 enhancements for inter-cell beam management Spreadtrum Communications

R1-2311212 Remaining issues on L1 enhancement for LTM Panasonic

R1-2311230 Remaining Issues of Inter-cell beam management enhancement OPPO

R1-2311350 Remaining issues on L1 enhancements for inter-cell beam management CATT

R1-2311368 Remaining issues of L1 enhancements for inter-cell beam management Lenovo

R1-2311409 Maintenance of L1 enhancements for inter-cell beam management xiaomi

R1-2311442 Maintenance on L1 enhancements for inter-cell beam management Google

R1-2311490 Remaining issues on L1 enhancements for inter-cell beam management CMCC

R1-2311510 Remaining issues on L1 enhancements for inter-cell beam management NEC

R1-2311514 Remaining issues on L1 enhancements for L1/L2-triggered Mobility KDDI Corporation

R1-2311593 Discussion on L1 enhancements for inter-cell beam management FGI

R1-2311629 Remaining issues on L1 enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2311692 L1 enhancements for inter-cell beam management Apple

R1-2311852 Remaining details on L1 enhancements for inter-cell beam management Samsung

R1-2311889 Remaining Issues on Layer-1 Enhancements for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2311934 Remaining issues on L1 enhancements for inter-cell beam management Ruijie Network Co. Ltd

R1-2311951 Remaining issues on L1 enhancements InterDigital, Inc.

R1-2311984 Remaining issues on L1 enhancements for inter-cell beam management MediaTek Inc.

R1-2312044 L1 Enhancements for Inter-Cell Beam Management Qualcomm Incorporated

R1-2311035 FL summary 1 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Tuesday session

Agreement

UE may expect that:

· For a candidate cell, the configuration of an LTM TCI state in ltm-DL-OrJointTCI-StateToAddModList-r18 and ltm-ul-TCI-ToAddModList-r18 is same as its counterpart in dl-OrJointTCI-StateList-r17 and ul-TCI-ToAddModList-r17 of the first active BWP in ServingCellConfig, at least in terms of TCI state ID, the corresponding qcl-Type1 and qcl-Type2 for the DL or joint TCI state or referenceSignal for the UL TCI state.

· The LTM TCI state(s) in ltm-DL-OrJointTCI-StateToAddModList-r18 and ltm-ul-TCI-ToAddModList-r18 of a candidate cell is a subset of serving cell TCI state(s) in dl-OrJointTCI-StateList-r17 and ul-TCI-ToAddModList-r17 of the same cell.

R1-2311036 FL summary 2 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Wednesday session

Agreement

Send an LS to RAN2 to inform the issue on MAC CE to activate/deactivate semi-persistent PUCCH report

· With an independent configuration of LTM CSI reporting which RAN2 has agreed, it is not clear how~~/whether~~ the activation/deactivation of semi-persistent PUCCH report for LTM CSI reporting is can be supported.

· RAN2 is respectfully asked to take this issue into account.

Comeback for draft LS to RAN2.

R1-2312547 [draft] LS on MAC CE to activate/deactivate semi-persistent PUCCH report for LTM Moderator (Fujitsu)

From Thursday session

Agreement

The draft LS in R1-2312547 is endorsed with the following revision:

With an independent configuration of LTM CSI reporting which RAN2 has agreed, the legacy MAC CE command cannot be used for LTM semi-persistent reporting on PUCCH because the ~~bits~~ ~~in the~~ MAC CE ~~are only associated with the ID for~~is used for the legacy CSI report configuration. It is not clear how the activation/deactivation of semi-persistent PUCCH report for LTM CSI reporting can be supported

Final LS is approved in R1-2312642.

R1-2311037 FL summary 3 on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Thursday session

Agreement

The TCI states in the candidate Cell TCI activation/deactivation command is associated with LTM TCI state pool of the target cell, i.e. configured under LTM-Candidate-r18.

Conclusion

No consensus to include simultaneousU-TCI-UpdateList under LTM-Candidate-r18 to activate and indicate TCI states for SCell(s) after cell switch command.

Conclusion

When RACH-less LTM is performed, for beam indication of target cell based on Rel-17 unified TCI framework applied to CORESET#0 and CORESETs (other than CORESET#0) associated with CSS sets other than Type3-PDCCH CSS sets where followUnifiedTCI-state is not enabled or not provided, whether using the TCI state indicated in the Cell Switch Command is up to UE implementation.

Agreement

· Processing of an LTM CSI report occupies 1 CPU

· CR to 38.214 is as follows

----------- Start of TP -----------

5.2.1.6 CSI processing criteria

The UE indicates the number of supported simultaneous CSI calculations with parameter simultaneousCSI-ReportsPerCC in a component carrier, and simultaneousCSI-ReportsAllCC across all component carriers. If a UE supports simultaneous CSI calculations it is said to have CSI processing units for processing CSI reports. If L CPUs are occupied for calculation of CSI reports in a given OFDM symbol, the UE has unoccupied CPUs. If N CSI reports start occupying their respective CPUs on the same OFDM symbol on which CPUs are unoccupied, where each CSI report corresponds to , the UE is not required to update the requested CSI reports with lowest priority (according to Clause 5.2.5), where is the largest value such that holds.

A UE is not expected to be configured with an aperiodic CSI trigger state containing more than Reporting Settings. Processing of a CSI report occupies a number of CPUs for a number of symbols as follows:

- for a CSI report with CSI-ReportConfig with higher layer parameter reportQuantity set to 'none' and CSI-RS-ResourceSet with higher layer parameter trs-Info configured

- for a CSI report with LTM-CSI-ReportConfig or a CSI report with CSI-ReportConfig with higher layer parameter reportQuantity set to 'cri-RSRP', 'ssb-Index-RSRP', 'cri-SINR', 'ssb-Index-SINR', 'cri-RSRP- Index', 'ssb-Index-RSRP- Index', 'cri-SINR- Index', 'ssb-Index-SINR- Index ' or 'none' (and CSI-RS-ResourceSet with higher layer parameter trs-Info not configured)

----------- End of TP -----------

R1-2311038 Final FL summary on L1 enhancements for inter-cell beam management Moderator (Fujitsu)

From Friday session

Agreement

The TCI state indicated in the cell switch command is associated with LTM TCI state pool of the target cell, i.e. configured under LTM-Candidate-r18.

Agreement

For the priority rule for CSI report, LTM CSI report is prioritized over legacy CSI report.

Conclusion

Accumulation of PUSCH/PUCCH/SRS closed loop power control for indicated target cell has been reset when the cell switch command takes effect.

Note: Necessity of the CR needs further discussion: come back in the future meeting if the necessity is identified.

Conclusion

The following proposal is not pursued in Rel-18.

A MAC CE is introduced to activate/deactivate the SSB(s)/cell(s) configured in the L1 measurement report.

Agreement

After RACH procedure until a new TCI state is indicated by the target cell, a UE follows the indicated TCI-state in the cell switch command at least for CFRA triggered by cell switch command.

Final summary revised in R1-2312678.

8.7.22 Timing advance management to reduce latency

R1-2310831 Remaining issues with UE based TA determination FUTUREWEI

R1-2310849 Maintenance of timing advance management to reduce latency Huawei, HiSilicon

R1-2310955 Maintenance on TA management to reduce latency ZTE

R1-2310973 Maintenance of TA management for LTM Ericsson

R1-2311106 Discussion on TA management for L1/L2-triggered Mobility vivo

R1-2311173 Remaining issues on timing advance management to reduce latency Spreadtrum Communications

R1-2311231 Remaining Issues of Timing Advance Management OPPO

R1-2311351 Remaining issues on TA management to reduce latency CATT

R1-2311369 Remaining issues of timing advance management for L1/L2 mobility Lenovo

R1-2311439 Remaining issues on TA management for mobility LG Electronics

R1-2311443 Maintenance on timing advance management to reduce latency Google

R1-2311491 Remaining issues on timing advance management to reduce latency CMCC

R1-2311592 Remaining issues on TA management for LTM FGI

R1-2311630 Remaining issues on TA enhancements for inter-cell mobility NTT DOCOMO, INC.

R1-2311693 Timing advance management for L1/L2 Mobility Apple

R1-2311853 Remaining issues on candidate cell TA management for NR L1/L2 mobility enhancement Samsung

R1-2311890 Remaining Issues on Timing Advance Management for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2311952 Remaining details on timing advance management InterDigital, Inc.

R1-2312045 TA management to reduce latency for L1/L2 based mobility Qualcomm Incorporated

R1-2312134 Discussion on TA management to reduce latency CAICT

R1-2312331 Moderator summary on timing advance management for LTM: Round 1 Moderator (CATT)

From Tuesday session

Agreement

Use clause 8.1 of 213 as the reference clause for the value of N used to determine the overlap scenario between the PRACH transmission to a candidate cell and an UL transmission to the serving cell.

Agreement

n-TimingAdvanceOffset is pre-configured to UE for each candidate cell.

Agreement

Endorse in principle the TP below

· Reason for change: specify the condition of performing UE-based TA estimation

· Summary for change: the configuration of each candidate cell includes a field ltm-UE-MeasuredTA-ID. If the value of ltm-UE-MeasuredTA-ID for the serving cell is the same as the value of ltm-UE-MeasuredTA-ID for the candidate, the UE would perform UE-based TA estimation. If the value of ltm-UE-MeasuredTA-ID for the serving cell is different from the value of ltm-UE-MeasuredTA-ID for the candidate, the UE would not perform UE-based TA estimation.

· Consequences if not approved: condition of performing UE-based TA estimation is not clear.

38.213 21 L1/L2-triggered Mobility Procedure

A UE can be indicated, by LTM-Config, candidate cells and SS/PBCH blocks per candidate cell for the UE to obtain synchronization and measure corresponding L1-RSRPs [10, TS 38.133]. A MAC CE command can activate TCI states, provided by LTM-Candidate-TCI-State-r18 or/and LTM-Candidate-TCI-UL-State-r18, associated with SS/PBCH blocks or TRS of corresponding candidate cells. The UE is provided configurations by LTM-CSI-ReportConfigToAddModList for reporting L1-RSRP measurements [6, TS 38.214] that include a number of candidate cells and a number of SS/PBCH blocks per candidate cell from the number of candidate cells.

If the ltm-UE-MeasuredTA-ID (if configured) of a candidate cell is equal to the ltm-UE-MeasuredTA-ID (if configured) of the serving cell, the UE estimates based on the UE implementation a timing advance to apply from a first transmission on a candidate cell that is after the reception of a cell switch command for the candidate cell [11, TS 38.321].

A UE can be provided configurations, by EarlyUlSyncConfig, for PRACH transmission parameters for each of the candidate cells. The UE can be triggered a PRACH transmission on a candidate cell by a PDCCH order that the UE receives on a serving cell and includes an indication of the candidate cell for the PRACH transmission [4, TS 38.212]. If the serving cell and the candidate cell operate in a same frequency range and the UE would have transmissions that overlap in time, or when a gap between a first or last symbol of a PRACH transmission to the candidate cell is less than 𝑁 symbols from a last or first symbol, respectively, of an UL transmission to the serving cell, where is defined in Clause TBD, the UE

- drops the transmissions on the serving cell when the UE does not support transmissions that overlap in time or are separated by less than the gap on the serving cell and the candidate cell

- prioritizes power allocation to the PRACH transmission on the candidate cell in clause 7.5 when the UE supports transmissions that overlap in time or are separated by less than the gap, and a total UE transmit power in the frequency range would exceed

The UE transmits the PRACH on the candidate cell as described in Clause 8.1 with a power determined as described in Clause 7.4.

R1-2312332 Moderator summary on timing advance management for LTM: Round 2 Moderator (CATT)

From Wednesday session

Agreement

The TP below is endorsed for TS 38.213 (TP to section 8.2)

· Reason for change: RACH based TA acquisition mechanism for candidate cells does not include UE receiving RAR corresponding to the PRACH transmission, however, such characteristic has not been captured in clause 8.2 TS 38.213. In other words, from perspective of RAN1 specification, UE still needs to detect PDCCH for RAR for a PRACH transmission towards a candidate cell. Hence, we suggest to capture the following text proposal for clarification.

· Summary of change: To specify that UE does not detect PDCCH RAR for a PRACH transmission triggered for a candidate cell.

· Consequence if not approved: RACH procedure without RAR for candidate cells is not supported from perspective of RAN1 specification.

8.2 Random access response - Type-1 random access procedure

In response to a PRACH transmission, a UE attempts to detect a DCI format 1_0 with CRC scrambled by a corresponding RA-RNTI during a window controlled by higher layers [11, TS 38.321]. If a PRACH transmission is triggered by PDCCH order with non-zero Cell Indicator Field, the UE does not attempt to detect a DCI format 1_0 with CRC scrambled by a corresponding RA-RNTI. The window starts at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type1-PDCCH CSS set, as defined in clause 10.1, that is at least one symbol, after the last symbol of the last PRACH occasion corresponding to the PRACH transmission, where the symbol duration corresponds to the SCS for Type1-PDCCH CSS set as defined in clause 10.1. If or , as defined in [4, TS 38.211], is not zero, the window starts after an additional msec where is defined in [4, TS 38.211] and is provided by kmac or if kmac is not provided. The length of the window in number of slots, based on the SCS for Type1-PDCCH CSS set, is provided by ra-ResponseWindow.

R1-2312564 Moderator summary on timing advance management for LTM: Round 3 Moderator (CATT)

From Thursday session

Conclusion

From RAN1 perspective, for a LTM candidate cell, PRACH for early TA acquisition can be performed on either UL or SUL in the LTM candidate cell.

· Whether to have only one RACH configuration or two RACH configurations is left to RAN2 decision.

Final summary in R1-2312565.

RAN1#116

8.55 Maintenance on Further NR Mobility Enhancements

R1-2401760 Session notes for 8.5 (Maintenance on Further NR Mobility Enhancements) Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

[116-R18-Mobility] – Yosuke (Fujitsu)

Email discussion on mobility enhancements

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2400038 Remaining issues on further NR Mobility Enhancements Spreadtrum Communications

R1-2400142 Maintenance of L1 enhancements for inter-cell beam management Huawei, HiSilicon

R1-2400186 FL plan for Maintenance on Further NR Mobility Enhancements at RAN1#116 Moderator (Fujitsu)

R1-2400193 Maintenance on further NR mobility enhancements Lenovo

R1-2400221 Maintenance on Further NR Mobility Enhancements vivo

R1-2400276 Maintenance on Further NR Mobility Enhancements ZTE

R1-2400452 Maintenance on NR mobility enhancements CATT

R1-2400581 Text Proposals on Further NR Mobility Enhancement OPPO

R1-2400646 Remaining Issues for L1/L2-triggered Mobility Nokia, Nokia Shanghai Bell

R1-2400680 Maintenance on Further NR Mobility Enhancements Langbo

R1-2400707 Maintenance on Further NR Mobility Enhancements Samsung

R1-2400763 Remaining issues on further NR mobility enhancements Fujitsu

R1-2400880 On missing specification on LTM TCI state configuration Panasonic

R1-2400911 Maintenance on Further NR Mobility Enhancements Ericsson

R1-2400991 Maintenance of further NR mobility enhancement Apple

R1-2401093 Maintenance on Further NR Mobility Enhancements NTT DOCOMO, INC.

R1-2401200 Discussion on early PRACH ASUSTeK

R1-2401255 Discussion on maintenance on further NR mobility enhancements Google

R1-2401312 On maintenance for mobility enhancements MediaTek Inc.

R1-2401582 FL summary 1 of Maintenance on Further NR Mobility Enhancements Moderator (Fujitsu)

From Monday session

Agreement

For RACH based LTM procedure, after the completion of RACH procedure, UE follows the indicated TCI-state in the LTM cell switch command.

Agreement

· The TP to Section, 5.2.1.4.2, TS38.214, is endorsed in principle.

Reason of change: For LTM L1 measurement report with SpCellInclusion configured, how to identify a SSB in a ltm-CSI-SSB-ResourceSet-r18 belonging to SpCell is not defined

Summary of change: Clarify that SpCell measurements are the entries in the LTM-CSI-SSB-ResourceSet where the PCI and ssbFrequency-r18 of the candidate cell is equal to the PCI and center frequency of SSB of the current SpCell.

Consequence if not approved: UE is not able to determine SSB of SpCell from ltm-CSI-SSB-ResourceSet-r18.

===== Start of TP for TS38.214 ======

5.2.1.4.2 Report quantity configurations

If a UE is configured with a LTM-CSI-ReportConfig,

- if the UE is configured with spCellInclusion, the UE shall report in a single reporting instance nrOfReportedRS-PerCell different SSBRI for the current SpCell and each of the [nrOfReportedCells] -1 candidate cells. Otherwise, the UE shall report in a single reporting instance [nrOfReportedRS-PerCell] different SSBRI for each of the [nrOfReportedCell] candidate cells,

- where SSBRI k (k ≥ 0) corresponds to the configured (k+1)-th entry of the associated ltm-CSI-SSB-ResourceListin the corresponding ltm-CSI-SSB-ResourceSet,

- if spCellInclusion is configured, SSB resources in ltm-CSI-SSB-ResourceList associated with the current SpCell are the entries where PCI given by ltm-CandidatePCI and frequency information given by ssbFrequency-r18 of the associated candidate cell (given in ltm-CandidateIdList) is equal to the PCI and center frequency of cell-defining SSB of the current SpCell.

===== End of TP for TS38.214 ======

Agreement

After reception of LTM cell switch command, UE deactivates all activated LTM TCI states other than indicated TCI state.

R1-2401583 FL summary 2 of Maintenance on Further NR Mobility Enhancements Moderator (Fujitsu)

Presented in Tuesday session.

R1-2401782 FL summary 3 of Maintenance on Further NR Mobility Enhancements Moderator (Fujitsu)

From Thursday session

Agreement

· Adopt the following TP (to remove the yellow colour while keeping the parameter) to Section 5.2.5, TS38.214 in principle.

Reason of change: The priority rules for LTM CSI reports are not defined when two or more LTM CSI reports are collided.

Summary of change: Add the priority rules for LTM CSI reports when two or more LTM CSI reports are collided.

Consequence if not approved: The priority rules for LTM CSI reports when two or more LTM CSI reports are ambiguous.

===== Start of TP for TS38.214 ======

5.2.5 Priority rules for CSI reports

For two overlapping PUSCHs, the priority rules in this clause are applied for physical channels with same priority index according to clause 9 in [6, TS 38.213] if a UE is not configured with enableSTx2PofmDCI or a UE is configured by higher layer parameter PDCCH-Config that contains two different values of coresetPoolIndex in ControlResourceSet and the UE is configured with enableSTx2PofmDCI and the two overlapping PUSCHs are associated with same value of coresetPoolIndex.

CSI reports are associated with a priority value where

- for aperiodic CSI reports to be carried on PUSCH for semi-persistent CSI reports to be carried on PUSCH, for semi-persistent CSI reports to be carried on PUCCH and for periodic CSI reports to be carried on PUCCH;

- for CSI reports carrying L1-RSRP or L1-SINR and for CSI reports not carrying L1-RSRP or L1-SINR;

- c is the serving cell index and is the value of the higher layer parameter maxNrofServingCells;

- for a CSI report configured with LTM-CSI-ReportConfig, c is the serving cell index value where the report configuration is configured.

- s is the reportConfigID and is the value of the higher layer parameter maxNrofCSI-ReportConfiguration for a CSI report configured with CSI-ReportConfig.

- for a CSI report configured with LTM-CSI-ReportConfig, s is the LTM-CSI-ReportConfigID and M_s is the value of the higher layer parameter maxNrofLTM-CSI-ReportConfigurations

A CSI report configured with LTM-CSI-ReportConfig has a higher priority over all CSI report(s) configured with CSI-ReportConfig irrespective of value in case of collision with CSI report(s) configured with CSI-ReportConfig.

===== End of TP for TS38.214 ======

Agreement

· Adopt the following TP to Section 21, TS38.213 in principle.

Reason of change: The beam application time for LTM is still TBD.

Summary of change: The beam application time for LTM is defined as no later than T_{LTM-RRC-processing} + T_{LTM-processing} + T_first-RS + T_RS-proc +3(ms).

Consequence if not approved: The beam application time for LTM is undefined.

===== Start of TP for TS38.213 ======

21 L1/L2-triggered mobility procedures

A UE can be provided by a MAC CE in a PDSCH reception on the serving cell [11, TS 38.321] a TCI-State and/or TCI-UL-State in LTM-dl-OrJointTCI-StateToAddModList and/or LTM-ul-TCI-ToAddModList indicating a unified TCI state [6, TS 38.214] for applicable receptions or transmissions on a candidate cell from the number of candidate cells. The UE applies the TCI-State and/or TCI-UL-State, if indicated by the MAC CE, no later than ~~from a first slot that is~~ T_{LTM-RRC-processing} + T_{LTM-processing} + T_first-RS + T_RS-proc +3 (ms) after the last symbol of a PUCCH or PUSCH with HARQ-ACK information for the PDSCH providing the MAC CE, where the components of T_{LTM-RRC-processing}, T_{LTM-processing}, T_first-RSand T_RS-proc are define in clause 6.3.1.3 of [11, 38.133]. ~~and~~ ~~is the SCS configuration for the TBD~~. If the MAC CE triggers a PRACH transmission [11, TS 38.321], the UE applies the TCI-State for receptions on the candidate cell, and applies a spatial domain filter corresponding to the TCI-State or the TCI-UL-State for transmissions on the candidate cell, that are after the completion of the random access procedure associated with the PRACH transmission on the candidate cell and before a new TCI state is indicated for the candidate cell.

===== End of TP for TS38.213 ======

Agreement

· Adopt the following TP to Section 21, TS38.213 in principle

Reason of change: Description on TCI state used after cell switch command is missing for RACH-less, CBRA and CFRA configured by RRC.

Summary of change: Add the description that TCI state used after cell switch command for RACH-less, CBRA and CFRA configured by RRC.

Consequence if not approved: TCI state used after cell switch command is missing for RACH-less, CBRA and CFRA configured by RRC is not clear.

===== Start of TP for TS38.213 ======

21 L1/L2-triggered mobility procedures

A UE can be provided by a MAC CE in a PDSCH reception on the serving cell [11, TS 38.321] a TCI-State and/or TCI-UL-State in LTM-dl-OrJointTCI-StateToAddModList and/or LTM-ul-TCI-ToAddModList indicating a unified TCI state [6, TS 38.214] for applicable receptions or transmissions on a candidate cell from the number of candidate cells. The UE applies the TCI-State and/or TCI-UL-State, if indicated by the MAC CE, from a first slot that is after the last symbol of a PUCCH or PUSCH with HARQ-ACK information for the PDSCH providing the MAC CE, and is the SCS configuration for the TBD. For RACH-less LTM cell switch, the UE applies the TCI-State for receptions on the candidate cell and applies a spatial domain filter corresponding to the TCI-State or the TCI-UL-State for transmissions on the candidate cell before a new TCI state is indicated for the candidate cell. For RACH-based LTM cell switch, the UE applies the TCI-State for receptions on the candidate cell, and applies a spatial domain filter corresponding to the TCI-State or the TCI-UL-State for transmissions on the candidate cell, that are after the completion of the random access procedure associated with the PRACH transmission on the candidate cell and before a new TCI state is indicated for the candidate cell.

===== End of TP for TS38.213 ======

Agreement

· Adopt the following TP to Section 21, TS38.213 in principle

Reason of change: QCL type for LTM TCI state and its configuration is not specified.

Summary of change: The DM-RS antenna ports of PDCCH and PDSCH are quasi co-located with the reference signal(s) in the provided TCI-state with respect to typeA and typeD. The UE does not expect to be configured with typeA when SSB is configured as a source RS of a LTM TCI state.

Consequence if not approved: It is not clear how the QCL type for LTM TCI state is configured and assumed.

===== Start of TP for TS38.213 ======

21 L1/L2-triggered mobility procedures

A UE can be provided by a MAC CE in a PDSCH reception on the serving cell [11, TS 38.321] a TCI-State and/or TCI-UL-State in LTM-dl-OrJointTCI-StateToAddModList and/or LTM-ul-TCI-ToAddModList indicating a unified TCI state [6, TS 38.214] for applicable receptions or transmissions on a candidate cell from the number of candidate cells. The UE may assume that the DM-RS antenna ports of PDCCH and PDSCH are quasi co-located with the reference signal(s) in the provided LTM TCI-state with respect to ‘typeA’ and ‘typeD’ when applicable [6, TS 38.214]. The UE does not expect to be configured with ‘typeA’ when SS/PBCH block is configured as a source RS of a LTM TCI state. The UE applies the TCI-State and/or TCI-UL-State, if indicated by the MAC CE, from a first slot that is after the last symbol of a PUCCH or PUSCH with HARQ-ACK information for the PDSCH providing the MAC CE, and is the SCS configuration for the TBD. If the MAC CE triggers a PRACH transmission [11, TS 38.321], the UE applies the TCI-State for receptions on the candidate cell, and applies a spatial domain filter corresponding to the TCI-State or the TCI-UL-State for transmissions on the candidate cell, that are after the completion of the random access procedure associated with the PRACH transmission on the candidate cell and before a new TCI state is indicated for the candidate cell.

===== End of TP for TS38.213 ======

Agreement

· Adopt the following TP to Section 21, TS38.213 in principle.

Reason of change: As for the LTM TCI states, it is not clear if the TCI states activated before cell switch command is retained or activated.

Summary of change: After reception of LTM cell switch command, UE deactivates all activated LTM TCI states other than indicated TCI state.

Consequence if not approved: It is not clear if the TCI states activated before cell switch command is retained or activated.

===== Start of TP for TS38.213 ======

21 L1/L2-triggered mobility procedures

A UE can be indicated, by LTM-Config, candidate cells and SS/PBCH blocks per candidate cell for the UE to obtain synchronization and measure corresponding L1-RSRPs [10, TS 38.133]. A MAC CE command can activate TCI states, provided by LTM-Candidate-TCI-State-r18 or/and LTM-Candidate-TCI-UL-State-r18, associated with SS/PBCH blocks or TRS of corresponding candidate cells. After reception of LTM Cell Switch Command MAC CE [11, TS 38.321], the activated TCI states other than the indicated TCI state in the LTM Cell Switch Command MAC CE are deactivated. The UE is provided configurations by LTM-CSI-ReportConfigToAddModList for reporting L1-RSRP measurements [6, TS 38.214] that include a number of candidate cells and a number of SS/PBCH blocks per candidate cell from the number of candidate cells.

===== End of TP for TS38.213 ======

R1-2401784 [draft] LS on TCI state after cell switch command for LTM Moderator (Fujitsu)

Decision: The draft LS in R1-2401784 is endorsed in principle. Final LS is approved in R1-2401785.

Final summary in R1-2401783.